37 lines
2.6 KiB
Markdown
37 lines
2.6 KiB
Markdown
# 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,0–2,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).
|