# Service Optimization: Schlanke Dienste für maximalen Durchsatz

TL;DR / Management Summary Arbeitsspeicher ist oft die teuerste Ressource im Rechenzentrum und die knappste im Edge-Bereich. Ein Senior Admin wählt Dienste nicht nach Beliebtheit, sondern nach Ressourcen-Effizienz. In diesem Modul vergleichen wir “schwere” Standard-Dienste mit ihren leichtgewichtigen Alternativen (z.B. SQLite statt MySQL, Go statt Java) und lernen, wie wir RAM-Limits auf Service-Ebene erzwingen, um das System vor dem OOM-Killer zu schützen.

# 1. Einführung & Architektur

Die Wahl der Waffen.

Jeder Dienst hat einen “Base-Memory-Footprint” (RAM-Verbrauch im Leerlauf). In minimalen Umgebungen summieren sich diese Werte schnell.

# Der Ressourcen-Vergleich (Mermaid)

graph LR
    subgraph "Heavy Stack"
        A[Apache Webserver] --- B[Java / JVM]
        B --- C[Full MySQL / Oracle]
    end
    subgraph "Lightweight Stack"
        D[Nginx / Caddy] --- E[Go / Rust / Node]
        E --- F[SQLite / Redis]
    end
    A/B/C -->|RAM Usage| G[High: > 2GB]
    D/E/F -->|RAM Usage| H[Low: < 200MB]

# 2. Die Alternativen im Detail

Wo wir sparen können.

# 1. Webserver

• Schwer: Apache2 (Prefork Modus). Jeder Worker braucht eigenen RAM.
• Leicht: Nginx (Event-basiert) oder Go-Webserver. Nginx kann zehntausende Verbindungen mit wenigen Megabyte RAM halten.

# 2. Datenbanken

• Schwer: MariaDB/PostgreSQL. Reservieren oft GB-weise RAM für Buffer-Pools.
• Leicht: SQLite. Perfekt für Applikationen mit niedriger Schreiblast. Kein eigener Dämon nötig!

# 3. Laufzeitumgebungen

• Schwer: Java (JVM) und Python (viele Imports).
• Leicht: Go oder Rust. Kompilierte Binaries verbrauchen nur das, was sie wirklich brauchen.

# 3. Ressourcen-Limits erzwingen

Den RAM-Hunger bändigen.

Nutzen Sie Cgroups v2 (via Systemd oder OpenRC), um Dienste zu deckeln.

# Beispiel: Nginx limitieren (systemd)

[Service]
# Der Dienst wird gekillt, wenn er mehr als 128MB verbraucht
MemoryMax=128M
MemoryHigh=100M

# 4. Day-2 Operations: Monitoring & Analyse

Wo verschwindet der RAM?

# pmap: Speicher-Mapping eines Prozesses

# Zeigt detailliert, welche Libraries wie viel RAM fressen
sudo pmap -x <pid> | sort -k 3 -n

# smem: Die Wahrheit über ‘Shared Memory’

Normale Tools wie top zeigen oft zu hohe Werte, da sie Shared Libraries mehrfach zählen. smem zeigt den PSS (Proportional Set Size) Wert.

sudo apk add smem
smem -r -k -t

# 5. Troubleshooting & “War Stories”

Wenn ‘leicht’ zu instabil wird.

# Story 1: “Der Java-OOM trotz Limits”

Symptom: Eine Java-Applikation im Container stürzt ständig ab, obwohl MemoryMax gesetzt ist. Ursache: Die JVM erkennt das Limit des Containers/Slices nicht und versucht, den gesamten RAM des Hosts zu nutzen. Lösung: Nutzen Sie moderne Java-Versionen (11+) mit dem Flag -XX:+UseContainerSupport oder setzen Sie die Heap-Größe explizit: -Xmx128m.

# Story 2: “SQLite Lock-Contention”

Symptom: Eine Web-App auf SQLite-Basis wird bei vielen parallelen Usern extrem langsam. Ursache: SQLite sperrt bei Schreibvorgängen die gesamte Datei. Lösung: SQLite ist ein Leichtgewicht, aber kein Allheilmittel. Bei hoher Schreiblast (Concurrent Writes) ist der Wechsel zu einer “schwereren” DB wie PostgreSQL unumgänglich. Optimieren Sie PostgreSQL dann über Shared Buffers (Artikel 162).

# 6. Fazit & Empfehlung

• Entscheidung: Wählen Sie Dienste basierend auf dem erwarteten Traffic. Für interne Tools ist SQLite fast immer ausreichend.
• Isolation: Nutzen Sie Cgroups, um Fehlverhalten eines Dienstes (Memory Leaks) vom restlichen System zu isolieren.
• Wahl: Alpine + Go/Rust ist die effizienteste Kombination für moderne Enterprise-Backend-Services.

# Anhang: Cheatsheet