108 lines
4.1 KiB
Markdown
108 lines
4.1 KiB
Markdown
# Memory-Limits Baseline - Vorbereitung F-19
|
|
|
|
Status: **Vorbereitung**. Echte `mem_limit`-Werte werden erst gesetzt, wenn mindestens 7 Tage realer Peak-Werte vorliegen.
|
|
|
|
Bezug: `docs/archive/2026-05/AUDIT_2026-05-25.md` F-19 "Keine Container-Memory-Limits".
|
|
|
|
## Warum nicht heute
|
|
|
|
Audit-TODO 2026-05-30: F-19 ist nicht akut. Im `docs/MIGRATION_LOG.md` ist **kein einziger** OOM-/Memory-Vorfall dokumentiert. `services/posture-check/docker-critical-events.sh` ueberwacht `die`/`oom`/`kill`-Events und alarmiert via ntfy — der Detektions-Pfad ist da, der Daten-Befund fehlt. Limits ohne Peak-Daten zu setzen bedeutet entweder zu eng (Flapping) oder so weit weg vom Realwert, dass die Schutzwirkung gegen Null geht.
|
|
|
|
Familien-Einladung verschiebt die Risiko-Bilanz nach oben: Ein OOM in Authelia/Postgres bei Familien-Nutzung kostet Vertrauen, nicht nur Operator-Zeit. Sobald die Einladung raus ist, wird F-19 ein "should" statt "nice".
|
|
|
|
## Plan
|
|
|
|
### Phase 1 - Peak-Beobachtung (7 Tage)
|
|
|
|
Auf dem Host stuendlich `docker stats --no-stream` snappen und in eine Textfile pro Container schreiben. Beispiel-Snippet fuer das Cron-Skript:
|
|
|
|
```bash
|
|
#!/usr/bin/env bash
|
|
# /boot/config/plugins/user.scripts/scripts/docker-stats-snapshot/script
|
|
set -euo pipefail
|
|
OUT="/mnt/user/services/policy-checks/docker-stats-$(date +%Y%m%d).log"
|
|
mkdir -p "$(dirname "$OUT")"
|
|
{
|
|
echo "=== $(date -Iseconds) ==="
|
|
docker stats --no-stream --format 'table {{.Name}}\t{{.MemUsage}}\t{{.MemPerc}}\t{{.CPUPerc}}'
|
|
} >> "$OUT"
|
|
```
|
|
|
|
Cron: stuendlich (`0 * * * *`), 7 Tage laufen lassen.
|
|
|
|
### Phase 2 - Peak-Auswertung
|
|
|
|
Pro Tier-1-Container das Maximum `MemUsage` aus dem 7-Tage-Log ableiten:
|
|
|
|
```bash
|
|
grep -E '^postgresql17|^authelia|^Redis|^vaultwarden|^gitea|^traefik|^komodo-mongo' \
|
|
/mnt/user/services/policy-checks/docker-stats-*.log \
|
|
| awk -F'\t' '{print $1, $2}' \
|
|
| sort -u
|
|
```
|
|
|
|
Erwartete Groessenordnungen (zur Plausibilitaetspruefung, nicht zur Festlegung):
|
|
|
|
| Container | Erwartung |
|
|
|---|---|
|
|
| postgresql17 | 200-600 MB |
|
|
| Redis | 30-80 MB |
|
|
| authelia | 50-150 MB |
|
|
| vaultwarden | 100-300 MB |
|
|
| gitea | 200-500 MB |
|
|
| traefik | 80-200 MB |
|
|
| komodo-mongo | 300-800 MB |
|
|
|
|
### Phase 3 - Limit-Setting
|
|
|
|
Pro Tier-1-Container:
|
|
|
|
```yaml
|
|
deploy:
|
|
resources:
|
|
limits:
|
|
memory: <peak * 1.5, mindestens floor>
|
|
```
|
|
|
|
Floor-Werte:
|
|
|
|
- postgresql17: 1G (Cache-Verhalten leidet bei weniger)
|
|
- komodo-mongo: 1G (WiredTiger braucht Working-Set)
|
|
- Redis: 256M (Paperless-Cache)
|
|
- vaultwarden: 256M
|
|
- gitea: 512M
|
|
- traefik: 256M
|
|
- authelia: 256M
|
|
|
|
`mem_reservation` bewusst nicht setzen — auf einem Single-Host-Setup ist Reservation Theater.
|
|
|
|
### Phase 4 - Rollout-Reihenfolge
|
|
|
|
1. Redis und authelia zuerst (kleinste Risiko-Container, klares Memory-Profil).
|
|
2. Wenn nach 48 h kein Flapping: traefik, vaultwarden, gitea.
|
|
3. Zuletzt postgresql17 und komodo-mongo, weil DB-Limits bei zu engem Setting Performance kippen.
|
|
|
|
Jede Stufe einzeln committen und 24 h beobachten.
|
|
|
|
### Phase 5 - Tier-2 (optional)
|
|
|
|
Tier-2 (Immich, Nextcloud, Paperless, Mealie, Mail-Archiver) bewusst spaeter, nur wenn ein konkreter Vorfall das rechtfertigt. Immich-ML ist der wahrscheinlichste Kandidat fuer den ersten echten OOM-Vorfall, deshalb dort zuerst beobachten, dann limitieren.
|
|
|
|
## Stop-Regel
|
|
|
|
Falls in Phase 3 ein Container nach Limit-Setzung haeufiger restartet als vor dem Limit: Limit raus, kein zweiter Versuch ohne dazwischenliegende Peak-Reanalyse. Doku-Eintrag in `docs/MIGRATION_LOG.md`, F-19 weiter offen.
|
|
|
|
## Was nicht ins Skript gehoert
|
|
|
|
- Mem-Limits sind kein Tuning, kein Performance-Hebel. Wer sich Performance erhofft, hat das falsche Werkzeug.
|
|
- Postgres-`shared_buffers` und `effective_cache_size` muessen zur Limit-Groesse passen. Setzen ohne Postgres-internes Tuning macht die DB langsamer, nicht stabiler.
|
|
- Komodo-Mongo waechst mit Stack-/Update-Historie. Limit fuer naechste 12 Monate planen, nicht fuer den heutigen Stand.
|
|
|
|
## Naechster Trigger
|
|
|
|
- Familien-Einladung raus, 4 Wochen stabile Nutzung, **oder**
|
|
- erster echter OOM-Vorfall im `docker-critical-events.sh`-Log, **oder**
|
|
- ein Immich/Nextcloud-Last-Sprung (z.B. grosses Foto-Backup), bei dem Host-Swap sichtbar wird.
|
|
|
|
Bei einem dieser Trigger: Phase 1 starten.
|