bolbol
/
nas-runbooks
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
nas-runbooks/common/runbook-audit-charge-nas-ds...

2.6 KiB
Raw Blame History

Runbook — Audit de charge NAS DS920+ : méthode et état de référence (2026-07-12)

Méthode de mesure (réutilisable)

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).