Diagnostic des fuites mémoire sur des serveurs avec perf, pmap et Valgrind

La diagnosis des fuites mémoire commence par l’observation : une consommation RAM qui augmente lentement, des entrées récurrentes du OOM-Killer ou une utilisation de swap inexpliquée sont des signaux d’alerte clairs. Dans cet article, je présente une procédure orientée pratique pour la diagnostic des fuites mémoire sur Linux-serveurs. Les méthodes combinent des inspections simples (pmap, /proc/*/smaps), des analyses par échantillonnage et Uprobe avec perf ainsi que des inspections profondes du tas avec Valgrind. L’objectif est de fournir aux administrateurs et aux system engineers un chemin de vérification fiable : prérequis, pièges typiques, commandes concrètes et stratégies de retour en arrière sûres.

Quand s’agit-il vraiment d’une fuite mémoire ?

Avant de lancer des outils : toute augmentation de la mémoire n’est pas forcément une fuite. Des sources typiques pouvant ressembler à des fuites sont des caches croissants, des fichiers mappés en mémoire (memory-mapped files), la fragmentation ou des pics de charge temporaires. Une fuite mémoire, au sens strict, est une occupation mémoire indésirable et non libérée dans un processus ou dans le noyau, qui croît de manière persistante dans le temps.

Indicateurs à vérifier :

• Augmentation monotone à long terme du RSS (Resident Set Size) d’un processus sur des heures/jours.
• Entrées OOM dans le journal du noyau associées au même processus.
• Valeurs élevées de Private-Dirty ou Private-Clean dans /proc/<pid>/smaps qui ne s’expliquent pas par des stratégies de cache légitimes.

Première observation : métriques et monitoring

Avant chaque session de debug, le problème doit être mesurable. Utilisez des outils de monitoring (par ex. Prometheus, Zabbix, Datadog) ou des commandes simples pour documenter les tendances. Capturez les grandeurs de base : RSS, VSZ, utilisation du swap, page-ins/outs et nombre de processus/threads.

# Einmalig RSS und VSZ eines Prozesses prüfen (PID bekannt vorausgesetzt)

ps -o pid,user,vsz,rss,cmd -p 1234

Interprétation : VSZ est l’espace d’adresses virtuel (incl. mmaps), RSS est la portion effectivement résidente en RAM. Une augmentation du RSS est un indicateur plus fort d’une fuite réelle.

# Systemweite Tendenzen: freier Speicher, Swap, Pageins/outs

vmstat 5 12

Si les page-outs et l’utilisation du swap augmentent en parallèle de la hausse du RSS, cela a une conséquence opérationnelle immédiate (dégradation des performances). Documentez les valeurs comme référence avant toute intervention.

Focalisation sur le processus : pmap, smaps et PSS

pmap affiche la table des mappings mémoire d’un processus. Il est utile pour repérer de grands mmaps (par ex. fichiers volumineux, shared memory). En complément, /proc/<pid>/smaps fournit des métriques détaillées comme la Pss (Proportional Set Size), Private_Dirty et Shared_Clean. La PSS répartit équitablement la taille des pages partagées entre les processus impliqués et est donc plus pertinente pour l’accounting.

# Detaillierte Zuordnung mit pmap

pmap -x 1234

# Smaps liefert pro-mapping Angaben (PSS, Private_Dirty, Referenced ...)

grep -A5 "^Rss: |^Pss: |^Private_Dirty:" /proc/1234/smaps | sed -n '1,200p'

Pratique : recherchez des mmaps avec un Private_Dirty anormalement élevé ou des valeurs PSS qui augmentent de façon continue. Des outils comme smem consolident la PSS par processus et sont utiles pour des rapports.

Échantillonnage avec perf : vérifier rapidement des hypothèses

perf est un outil de performance basé sur le noyau. En diagnostic, il aide à localiser les hotpaths et les chaînes d’appel. Pour les fuites mémoire, nous utilisons deux schémas :

• Échantillonnage des piles CPU pour identifier les chemins de code qui provoquent des allocations mémoire ou la croissance du cache.
• Uprobes (sondes en espace utilisateur) sur des allocateurs comme malloc, realloc ou mmap, pour observer les appels d’allocation effectifs.

Important : Pour perf, vous avez besoin des droits appropriés (root ou ajustement de /proc/sys/kernel/perf_event_paranoid) et idéalement des symboles de debug, afin que les traces de pile aient du sens. Les Uprobes ne fonctionnent que si la bibliothèque/exécutable à instrumenter est stable et que les chemins sont connus.

# Uprobe auf malloc registrieren (glibc als Beispiel) - nur als root

perf probe -x /lib/x86_64-Linux-gnu/libc.so.6 malloc

# Sampling von malloc-Aufrufen für PID 1234 über 30 Sekunden

perf record -e probe:libc:malloc -p 1234 -g -- sleep 30

# Auswertung

perf report -i perf.data --stdio

Warum das funktioniert: Uprobes erlauben, Funktionsaufrufe in Userland zu erfassen; kombiniert mit Callchains (Stacktraces) sehen Sie, welcher Anwendungscode häufig Allokationen triggert. Wann es scheitert: statisch gelinkte Binaries, JIT-kompilierte Prozesse oder stripped binaries liefern kaum aussagekräftige Symbole.

Traces perf alternatives

Sie können auch Tracepoints für sys_enter_mmap oder Kernel-Events wie kmem:kmalloc (für Kernel-Leaks) nutzen:

# mmap syscalls beobachten

perf record -e syscalls:sys_enter_mmap -p 1234 -g -- sleep 30

Ces données indiquent si le processus crée de nombreux mmaps — typique d’un cache memory-mapped en croissance ou d’un comportement côté bibliothèque.

Analyse approfondie du heap avec Valgrind

Valgrind (Memcheck) est un outil d’analyse dynamique qui détecte les fuites mémoire et les lectures/écritures invalides. Il ne remplace pas la supervision en production : Valgrind augmente fortement le temps d’exécution et l’utilisation mémoire et doit être exécuté dans un environnement de test ou de staging reproduisant le comportement de production.

Options importantes :

# Klassische Leak-Analyse

valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes --log-file=valgrind.log ./your_binary --args

# Massif für Heap-Profiling (Heap-Snapshot über Zeit)

valgrind --tool=massif --pages-as-heap=yes --massif-out-file=massif.out ./your_binary --args
# Visualisierung auf dem Admin-Desktop
ms_print massif.out

Pourquoi Valgrind : Memcheck détecte les fuites réelles (alloc sans free) et affiche des callstacks précis si le binaire et les bibliothèques sont compilés avec des symboles de debug. Limitations : les langages basés sur GC (par ex. runtimes managés) ou les serveurs asynchrones complexes se comportent différemment sous Valgrind ; les navigateurs ou les gros services sont souvent impraticables.

Pièges typiques et comment les éviter

• Exécutions de Valgrind en production : à éviter. Utilisez un environnement de staging ou capturez via core dumps et analysez hors ligne.
• Fragmentation vs fuite : parfois la mémoire virtuelle et résidente augmente à cause de la fragmentation. Vérifiez avec /proc/<pid>/smaps et des outils comme malloc-stats de votre implémentation malloc.
• Shared Memory und mmaps: Große mmaps können als RSS erscheinen, sind aber nicht notwendigerweise leaks—kontrollieren Sie Backing-Files.
• Threads und TLS: Thread-spezifische Caches (Thread-Local Storage) erhöhen persistenten Speicher, besonders bei hoher Threadanzahl.

Wenn Valgrind nicht praktikabel ist: Alternativen

Für produktionsnahe Heap-Analysen ohne Valgrind bieten sich an:

• jemalloc mit Built-in Profiling (jeprof)
• gperftools (tcmalloc) Heap-Profiler
• heaptrack (sampling-basierte userland-Analyse)
• ASan/LSan (Address/LeakSanitizer) während des Build-/Test-Prozesses — besser für CI als für Produktion

Diese Tools sind in der Regel weniger invasiv als Valgrind und können in (angepasster) Staging- oder Canary-Umgebung laufen.

Pragmatischer Prüfablauf — Checkliste

1. Beobachten: Trenddaten aus Monitoring exportieren, RSS/RAM/Swap-Verhalten dokumentieren.
2. Per-Prozess-Fokus: ps, top, pmap -x und /proc/<pid>/smaps analysieren. Ziel: Prozess-ID und betroffene Mappings bestimmen.
3. Sampling mit perf: Uprobes auf malloc/realloc/free oder syscalls wie mmap setzen; Callchains auswerten.
4. Reproduzieren in Staging: Valgrind (Memcheck) und Massif laufen lassen, Heap-Dumps erzeugen und auswerten.
5. Fix entwickeln: Objektfreigabe, Cache-Grenzen, Pooling oder Austausch von Allocator/Libs.
6. Deploy mit Canary: Versions- und Rollback-Plan, Monitoring-Alerts definieren.
7. Postmortem: Ursache, Indikatoren, Fix und automatisches Monitoring-Alerting dokumentieren.

Sichere Betriebs- und Rückfallstrategien

Diagnosen können riskant sein: perf mit uprobes ist minimal-invasiv, Valgrind disruptiv. Führen Sie invasive Tests nie direkt in Production durch. Wenn ein Fix ausgerollt wird, halten Sie einen schnellen Rollback bereit (Package-Repository, Service-Manager-Skript, Kubernetes-Revision). Definieren Sie Alert-Level: z. B. Warnung bei Anstieg um 20 % in 1 Std., kritischer Alarm bei OOM-Einträgen.

Kernel-Seite: Slab- und Kernel-Leaks

Manchmal sind Leaks kernelseitig (Slab-Allocator, Netzwerkbuffers). Prüfen Sie:

# Slab-Statistiken

slabtop -s c

# Kernel dmesg auf OOM oder allocation failures prüfen

dmesg --ctime | tail -n 200

Kernel-Leaks sind deutlich schwieriger und erfordern meist Kernel-Profile oder Live-Patching; als Admin dokumentieren Sie Fundstücke und eskalieren an Kernel-Entwickler oder Vendor-Support.

Praktische Beispiele — kurze Workflows

1) Schnelltest auf steigende mmaps (Produktiv, gering invasiv):

# Beobachtung: welche Prozesse verursachen viele mmaps in kurzer Zeit
perf record -e syscalls:sys_enter_mmap -a -g -- sleep 30
perf script | head -n 200

2) Uprobe auf malloc in Staging (zuordnen, welche Callchains viele Allokationen auslösen):

perf probe -x /lib/x86_64-Linux-gnu/libc.so.6 malloc
perf record -e probe:libc:malloc -p 1234 -g -- sleep 60
perf report -i perf.data --stdio

3) Valgrind-Memcheck in Testumgebung:

valgrind --leak-check=full --show-leak-kinds=all --log-file=valgrind.log ./service_binary --config /etc/service/conf

Speicherleck-Diagnose: weiterführende Strategien für komplexe Umgebungen

Dans des environnements d’hébergement réels, les services s’exécutent rarement de manière isolée. Les conteneurs, les unités systemd, les sidecars ou les bibliothèques partagées modifient la situation et exigent des méthodes de travail adaptées.

Conteneurs et cgroups (conseils pratiques)

Dans les environnements de conteneurs, les cgroups limitent la consommation mémoire. Un processus peut présenter une fuite, mais il est tué plus tôt en raison de la limite imposée par le cgroup. Vérifiez les statistiques des cgroups :

# cgroup v1 Beispiel (Pfad anpassen)
cat /sys/fs/cgroup/memory/docker//memory.usage_in_bytes
cat /sys/fs/cgroup/memory/docker//memory.max_usage_in_bytes
# cgroup v2 Beispiel
cat /sys/fs/cgroup//memory.current
cat /sys/fs/cgroup//memory.max

Conseils : dans Kubernetes, vérifiez les Events (kubectl describe pod) et les logs des conteneurs ; fixez des limites conservatrices afin qu’une fuite reste reproductible sans détruire immédiatement l’environnement.

Runtimes gérés : Java, Go, Node.js

Valgrind est souvent inadapté pour les runtimes gérés. Utilisez les profileurs natifs du runtime :

• Java : jmap/jcmd/jstack, Heap Dumps analysés avec Eclipse MAT (Memory Analyzer Tool).
• Go : runtime/pprof, interface pprof, profils heap via net/http/pprof.
• Node.js : heapdump, –inspect, profilage heap de V8.

# Beispiel: Go-Profil aktivieren (Servercode muss pprof importieren)
# Zugriff lokal: go tool pprof http://localhost:6060/debug/pprof/heap
# Beispiel: Java Heap-Dump erzeugen
jmap -dump:live,format=b,file=heap.hprof 
# Analyse lokal mit Eclipse MAT
mat heap.hprof

Ces outils fournissent des snapshots de heap, des graphes de références et des arbres de dominants qui montrent quels objets retiennent la mémoire.

Builds de débogage, Sanitizers et flags de compilation

Pour des analyses reproductibles, les développeurs doivent fournir des builds de débogage et des sanitizers. Flags de compilation importants :

# Beispiel GCC/Clang Debug/Sanitizer-Flags
CFLAGS="-g -O0 -fsanitize=address,leak -fno-omit-frame-pointer"
# Für ASan/LSan in Tests verwenden; nicht für Produktion

Pourquoi : les symboles de débogage rendent les traces d’appel exploitables. ASan/LSan détectent rapidement les use-after-free et les fuites lors des tests ; leurs limites sont le surcoût en performance et d’autres modifications du comportement à l’exécution.

Automatisation, CI et vérifications annuelles

Les fuites mémoire sont souvent latentes et se manifestent sous une charge prolongée. Planifiez des vérifications automatisées :

• Régression nocturne dans la CI avec sanitizers et workloads reproductibles.
• Exécutions périodiques de Massif en staging avec une charge connue, rapports basés sur des artefacts dans le dépôt d’artefacts.
• Playbooks d’alerte qui, en cas d’augmentation du RSS, génèrent automatiquement un snapshot (pmap/smaps) et lancent un court échantillonnage perf.

# Beispiel-Skript: bei Alarm automatisch pmap+smaps anlegen
#!/bin/bash
PID=$1
OUTDIR=/var/tmp/heap-dumps/$(date +%F_%T)
mkdir -p "$OUTDIR"
pmap -x "$PID" > "$OUTDIR/pmap.txt"
cp /proc/$PID/smaps "$OUTDIR/smaps"
# optional: perf kurz laufen lassen
perf record -e probe:libc:malloc -p $PID -g -- sleep 10
mv perf.data "$OUTDIR/"

Les artefacts automatisés aident les développeurs à reconstituer plus rapidement l’état reproductible.

Métriques mesurables et exemples Prometheus

Définissez des métriques claires dans Prometheus pour les règles d’alerte :

# PromQL-Beispiel: plötzlicher RSS-Anstieg über 1 Stunde
increase(process_resident_memory_bytes{job="myservice"}[1h]) > 200000000
# oder: relative Änderung
(rate(process_resident_memory_bytes{job="myservice"}[15m]) > 1048576)

Complétez avec application-instrumentation : métriques de la taille du heap de la runtime, nombre de caches ouverts, taux de cache hit/miss — ainsi il est plus facile de distinguer les fuites d’une croissance légitime des caches.

Plan de rollback et runbook d’urgence

Un rollback propre est impératif. Exemples d’étapes pour des services systemd :

# Beispiel Rollback (systemd unit)
# 1. Stoppen neuer Pods / Dienste
systemctl stop myservice
# 2. Deploy alte Version (aus Repo oder Paket)
apt-get install --allow-downgrades myservice=1.2.3-1
# 3. Starten und Monitoren
systemctl start myservice
journalctl -u myservice -f --lines=200

Dans Kubernetes, utilisez les mécanismes de rollback (kubectl rollout undo) et assurez-vous que les alertes sont désactivées pendant le rollback ou placées dans une fenêtre de maintenance du monitoring.

Quand escalader — support fournisseur ou support noyau

Escaladez lorsque :

• vous observez des indicateurs clairs du noyau (croissance des slabs, échecs d’allocation).
• les backtraces de processus pointent vers du code de bibliothèque que vous ne maintenez pas vous‑même (p. ex. glibc, bibliothèque tierce).
• vous constatez des fuites mémoire reproductibles dans des services managés et qu’il n’existe pas de contournement raisonnable.

Préparez pour les cas de support ces artefacts : extrait de dmesg, snapshot slabtop, pmap/smaps, perf captures, Valgrind-logs ou heap-dumps et étapes de reproduction exactes.

Résumé et conclusion

La diagnostic des fuites mémoire peut être menée de manière systématique et itérative : laisser le monitoring détecter le problème, utiliser pmap/smaps pour restreindre le périmètre, employer perf (incl. Uprobes) pour des tests d’hypothèses rapides et Valgrind pour des analyses profondes du heap dans un environnement adapté. Moyens supplémentaires : profileurs natifs de la runtime (jemalloc, heaptrack), Sanitizer en CI et génération automatisée d’artefacts lors d’alertes. Conditions préalables importantes : droits administratifs pour perf, symboles de debug pour une meilleure interprétation des chaînes d’appels et environnements de staging isolés pour les outils d’analyse invasifs. Sources fréquentes d’erreur : caches, mmaps ou fragmentation — celles‑ci doivent toujours être examinées comme causes potentielles avant de recourir à des mesures de debugging invasives. En conclusion : planifiez chaque étape avec une stratégie de rollback, documentez les artefacts et les alertes et coordonnez étroitement avec les équipes de développement afin que les correctifs puissent être reproduits et déployés en production en toute sécurité.

Remarques complémentaires : envisagez l’utilisation de profileurs spécifiques aux allocateurs (jemalloc, tcmalloc) en cas de problèmes récurrents ; ceux‑ci sont souvent plus adaptés à la production que Valgrind. Maintenez des builds de debug et des scripts de reproduction prêts, afin que les développeurs puissent rapidement comprendre et reproduire ce que vous avez observé lors de l’analyse.