Disque et mémoire : méthode complète

Prérequis : cours 2.3 (LVM), 1.2-1.3 (pression mémoire).

Pourquoi

« Plus de place » et « plus de mémoire » sont les deux pannes les plus fréquentes — et les plus mécaniques : une méthode, pas du talent, suffit dans 95 % des cas.

Concepts : disque, dans l'ordre

1. df -h (plein ?) + df -i (inodes épuisés = même panne, autre compteur !).
2. du -sh /* puis descendre (du -sh /var/*) : qui grossit.
3. Fantômes : lsof | grep deleted (supprimé mais ouvert).
4. Soulager : vacuum journal, prune Docker, rotation ; traiter : LVM extend, quotas, logrotate.

Concepts : mémoire, dans l'ordre

1. free -h : disponible vs cache (le cache est normal et libérable ! available = la vraie valeur, pas free).
2. Qui : ps aux --sort=-%mem | head, systemd-cgtop, smem (PSS : mémoire partagée comptée juste).
3. Pression : /proc/pressure/memory (some avg10), swap qui monte = alerte.
4. OOM : dmesg | grep -i "killed process" (qui a été tué et pourquoi).

Exemple : les 4 commandes qui disent tout

df -h; df -i; free -h; uptime
# 30 secondes : disque (Go + inodes), mémoire (available !), charge

Cas réel

« L'app fuit » : en fait les uploads s'accumulaient depuis 2 ans (pas de purge) + inodes à 98 % (millions de mini-fichiers de session !). Purge + tâche planifiée + alerte inodes (pas que Go !). Deux compteurs, deux sauvetages.

Pièges

• free vs available : free bas + cache haut = normal. available bas = vrai problème.
• Inodes oubliés : des millions de petits fichiers remplissent les inodes avec 50 % du disque libre. df -i systématique.
• Swappiness à 60 par défaut : serveur applicatif → 10 (swapper en dernier, pas au premier pic de cache).

À retenir

df + df -i, available pas free, PSS pour les partagés, OOM dans dmesg, inodes systématiques.