runbook: audit charge NAS DS920+ methode + etat de reference 2026-07-12

This commit is contained in:
bolbol 2026-07-12 13:12:03 +00:00
parent 969e297c5c
commit cbc9fc9a18
1 changed files with 36 additions and 0 deletions

View File

@ -0,0 +1,36 @@
# Runbook — Audit de charge NAS DS920+ : méthode et état de référence (2026-07-12)
## Méthode de mesure (réutilisable)
```bash
ssh nas '/usr/local/bin/docker stats --no-stream --format "{{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}\t{{.MemPerc}}"'
ssh nas 'free -m; cat /proc/loadavg; nproc; uptime'
ssh nas 'ps aux --sort=-%cpu | head -12; ps aux --sort=-rss | head -8'
```
### Pièges de lecture (Synology)
- Le `uptime` DSM décompose le loadavg en `[IO: x CPU: y]`**lire la part CPU**, le total inclut l'attente disque.
- Un scan de fichiers depuis le Mac (find/ls sur /Volumes/docker en SMB) fait monter `smbd` à 80 %+ CPU → fausse le load 1 min. Mesurer avant/sans scan.
- `docker stats` = mémoire cgroup (sans cache) ≠ RSS hôte via `ps`. Ex. qbittorrent : 434 Mo cgroup vs 1,83 Go RSS.
- Swap utilisé ≠ pression actuelle : croiser avec `Dirty` (/proc/meminfo) et l'activité kswapd.
## État de référence 2026-07-12 (42 containers)
- RAM : 6,4 / 19,85 Go utilisés, ~12,9 Go disponibles ; somme RSS containers ≈ 4,8 Go ; swap 3,2 Go (résiduel).
- CPU (J4125, 4 cœurs) : ~27 % en moyenne 15 min.
- **Goulot réel = IO disque** : load IO soutenu 2,02,4 (btrfs + Postgres n8n/Baserow + SQLite multiples). La machine plafonnera par l'IO avant la RAM/CPU.
- Top RAM : Baserow stack 1,3 Go ; Hermes ×3 1,3 Go ; qbittorrent 1,83 Go RSS ; n8n 413 Mo.
- Top CPU steady : crowdsec ~11 %, ActiveInsight 3,5 % (**obligatoire, ne pas désactiver — protection DSM**), dockerd 3 %.
## Décisions actées
- media-stack (prowlarr/radarr/sonarr) supprimé volontairement le 04/07 ; data conservée `/volume1/docker/media-stack/`.
- wg-easy retiré : VPN NAS = **Tailscale**. WireGuard ne subsiste que sur le VPS (KeepSolid). `wg-admin-client` = client tunnel.
- Verdict capacité : Family Help prod + nyora-veille passent sans dégradation (<300 Mo en pointe, LLM via Bifrost). Ne pas ajouter de service IO-intensif sans mesure préalable.
## Actions en attente
1. Purger l'orphelin flaresolverr : `docker stop flaresolverr && docker rm flaresolverr` (plus de client depuis la suppression de prowlarr).
2. Appliquer la limite hermes-agent-perso 600→768 Mo (déjà stagée dans le compose racine) :
`cd /volume1/docker/hermes-platform && /usr/local/bin/docker compose up -d --force-recreate hermes-agent-perso`
puis vérifier `stat -c '%u:%g' hermes-perso/data` = 1026:100 et health = healthy.
## Ce qui NE marche PAS
- Backup de `hermes-perso/data` (4 Go dont 1,2 Go .browsers) via le montage SMB du Mac : cp/rsync time-out. Faire les copies côté NAS.
- `ports-registry.md` dérive vite : resync v4 fait le 12/07 (source de vérité = docker ps réel).