# Constraint Management: Linux auf schwacher Hardware bändigen

TL;DR / Management Summary Nicht jeder Linux-Host verfügt über 64GB RAM und 16 Kerne. Im Edge-Computing, bei IoT-Gateways oder auf alten Legacy-Servern zählt jedes Megabyte. In diesem Modul lernen wir, wie wir Alpine und Arch für Umgebungen mit weniger als 512MB RAM optimieren. Wir nutzen Techniken wie zRAM (komprimierter RAM-Swap), deaktivieren ungenutzte Kernel-Module und lernen, wie wir mit Pressure Stall Information (PSI) Engpässe erkennen, bevor das System einfriert.

# 1. Einführung & Architektur

Der Kampf um den RAM.

In ressourcenarmen Umgebungen ist der RAM der kritischste Flaschenhals. Wenn der RAM voll ist, beginnt das System zu “swappen” (auf die langsame Disk zu schreiben), was die Performance zerstört.

# Die Architektur-Tricks (Mermaid)

graph TD
    A[Limited Hardware: 512MB RAM] --> B[zRAM: Compressed RAM Swap]
    A --> C[Kernel Tuning: Reduce Cache]
    A --> D[Minimal Init: OpenRC / runit]
    B --> E[Free Memory Increase: ~2x]
    C --> F[Lower Memory Pressure]
    D --> G[Faster Boot / Lower Background Load]

# 2. zRAM: Mehr RAM durch Kompression

Die Rettung für 512MB-Systeme.

zRAM erstellt ein virtuelles Block-Device im RAM, das Daten vor der Auslagerung komprimiert (z.B. mit Zstd). Dies ist bis zu 3x schneller als echtes Swapping auf Disk.

# Einrichtung unter Alpine

apk add zram-init
# Konfig in /etc/conf.d/zram-init
# type="zstd"
# size="50%" (Nutzt die Hälfte des RAMs als komprimierten Swap)
rc-update add zram-init default
rc-service zram-init start

# 3. Kernel & Service Stripping

Ballast abwerfen.

# 1. Unnötige TTYs deaktivieren

Jedes offene Terminal (getty) verbraucht RAM. Auf einem Headless-Server reicht ein TTY aus. Datei: /etc/inittab (SUSE/Alpine)

# Auskommentieren von tty2 bis tty6
# tty2::respawn:/sbin/getty 38400 tty2

# 2. Kernel-Parameter optimieren

Datei: /etc/sysctl.conf

# Aggressiveres Freigeben von Inode/Dentry Caches
vm.vfs_cache_pressure = 200
# Späteres Swapping (da Disk langsam)
vm.swappiness = 10

# 4. Day-2 Operations: Monitoring mit PSI

Druck im Kessel messen.

Anstatt nur auf free -m zu schauen, nutzen wir Pressure Stall Information (PSI). Es zeigt uns, wie lange Prozesse auf CPU, RAM oder I/O warten mussten.

# Zeige Druck auf dem Arbeitsspeicher
cat /proc/pressure/memory
# avg10, avg60, avg300 zeigen die prozentuale Verzögerung

# 5. Troubleshooting & “War Stories”

Wenn der OOM-Killer zuschlägt.

# Story 1: “Der plötzliche Tod des Webservers”

Symptom: Nginx ist sporadisch offline, im Log steht nichts. dmesg zeigt jedoch: Out of memory: Kill process 1234 (nginx). Ursache: Ein PHP-Skript hat bei einem großen Datei-Upload den RAM gesprengt. Lösung: Nutzen Sie OOM-Score-Adjust, um systemkritische Dienste vor dem Killen zu schützen, oder limitieren Sie die Ressourcen via Cgroups (Artikel 007).

# Story 2: “Das hängende System bei Disk-Schreibzugriffen”

Symptom: Sobald der Server Logs schreibt, friert die Konsole für Sekunden ein. Ursache: Ein langsames Speichermedium (z.B. SD-Karte im Raspberry Pi) blockiert den gesamten I/O-Stack. Lösung: Minimieren Sie Disk-Writes. Nutzen Sie ein tmpfs für /var/log und /tmp, damit temporäre Daten nur im RAM leben.

# 6. Fazit & Empfehlung

• Wahl: Alpine Linux ist für ressourcenarme Umgebungen die ungeschlagene Nummer 1.
• zRAM: Aktivieren Sie zRAM auf jedem System mit weniger als 2GB RAM.
• Wartung: Überwachen Sie PSI-Werte, um Hardware-Upgrades rechtzeitig planen zu können.

# Anhang: Cheatsheet