Tool um Kernel Memory Leak finden

Welches Modul/Treiber für welche Hardware, Kernel compilieren...
Antworten
nudgegoonies
Beiträge: 939
Registriert: 16.02.2009 09:35:10

Tool um Kernel Memory Leak finden

Beitrag von nudgegoonies » 20.01.2017 10:05:47

Hallo zusammen,
auf einem Jessie Rechner mit Backportkernel 4.8.11 und Docker 1.12.6 und vielen, vielen Container Stops und Starts (eine Art Batchprocessing) kam es zu einem Memoryleak im Kernel. Selbst nachdem alle Container und Docker beendet waren fehlte Speicher. Die Container waren alle beendet und die CGROUPS und MOUNTS sahen auch normal aus. Eine Analyse der laufenden Prozesse zeigte keinen Speicherschlucker an. Eine Analyse der Kernel-Module zeigte keines an, das viel Speicher brauchte. Das RAM kann also nur noch der Kernel selbst verschluckt haben. Mit welchem Tool kann ich herausfinden was im Kernel so viel Speicher schluckt? Ich habe slabtop noch gefunden, aber da muss ich mich noch einlesen. /proc/vmalloc zeigte als größten Platzschlucker pcpu_get_vm_areas an (über 1000 Zeilen), aber das sagt mir leider noch gar nichts. Gibt es da ein Tool, was ala TOP anzeigt welche fest im Kernel eincompilierte Komponente das meiste RAM schluckt?
Viele Grüße!
Soft: Bullseye AMD64, MATE Desktop. Repo's: Backports, kein Proposed, eigene Backports. Grafik: Radeon R7 360 MESA.
Hardware: Thinkstation S20, Intel X58, 16GB, Xeon W3530, BCM5755 NIC, EMU10K1 SND, SATA SSD+HDS und DVD+RW.

Milbret
Beiträge: 827
Registriert: 26.05.2008 12:04:54
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Nörten-Hardenberg
Kontaktdaten:

Re: Tool um Kernel Memory Leak finden

Beitrag von Milbret » 20.01.2017 19:41:01

Ich würde mal mit htop nach Prozessen suchen, die viel RAM fressen.
Alternativ hilft auch ein Blick mit atop um zu schauen wo der Speicher fehlt.
Auch wäre die Frage wie sich das Problem genau äußert.
Aktuell fehlt hier die Information wie dieses Leak aussieht.

Da du einen Backports Kernel verwendest, würde ich fast nicht von einem Leak sprechen.
Normalerweise müssen auch die Backport Kernels ordentlich erprobt sein.
Einfach einen 0815 Kernel wird man selbst in Backports nicht so bekommen, würde mich zumindestens wundern.

Mit genaueren Details kann man hier vielleicht mal schauen ob es ein Leak oder einfach nur von Linux genutzter RAM für den Dateisystem Cache ist.
Aber mit htop/atop könntest du schon einmal ein stück mehr sehen.
Wenn da nichts brauchbares zu sehen ist, müsste man wirklich tiefer graben.

Martin
Es gibt keine if Schleife -> http://www.if-schleife.de/
Ansonsten GPL/GNU/Linux/Debian/Free Software 4 Ever :D

rendegast
Beiträge: 15041
Registriert: 27.02.2006 16:50:33
Lizenz eigener Beiträge: MIT Lizenz

Re: Tool um Kernel Memory Leak finden

Beitrag von rendegast » 20.01.2017 20:51:03

Code: Alles auswählen

checkrestart 
checkrestart -v
(Debiandebian-goodies) ?

Code: Alles auswählen

lsof | grep delet
?



Auf einem suse LEAP habe ich gerade 'zypper dup' gemacht,
und 'zypper ps' zeigte mir weiterhin Sachen an, die in 'htop' nicht mehr zu sehen waren,
aber auch nicht in 'lsof | grep delet'.
(kann natürlich auch ein Problem mit zypper sein)
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")

nudgegoonies
Beiträge: 939
Registriert: 16.02.2009 09:35:10

Re: Tool um Kernel Memory Leak finden

Beitrag von nudgegoonies » 21.01.2017 17:22:20

Milbret hat geschrieben:Ich würde mal mit htop nach Prozessen suchen, die viel RAM fressen.
Alternativ hilft auch ein Blick mit atop um zu schauen wo der Speicher fehlt.
Auch wäre die Frage wie sich das Problem genau äußert.
Aktuell fehlt hier die Information wie dieses Leak aussieht.
[...]
Mit genaueren Details kann man hier vielleicht mal schauen ob es ein Leak oder einfach nur von Linux genutzter RAM für den Dateisystem Cache ist.
Aber mit htop/atop könntest du schon einmal ein stück mehr sehen.
Wenn da nichts brauchbares zu sehen ist, müsste man wirklich tiefer graben.
Danke für die Antwort. Prozesse haben wir schon wie beschrieben schon geschaut (htop). Die sind es nicht. Buffers und Cache sind sehr klein und sind es auch nicht (können auch nicht größer werden weil der Kernel ja so viel RAM schluckt). Module brauchen auch nicht viel RAM (lsmod). Mit der Zeit konnten immer weniger Container auf dem Rechner gestartet werden, bis der Rechner überhaupt keine neuen Container mehr abkriegte. Wir hatten Docker im Visier und haben alle noch laufenden Container beendet und danach den Docker Daemon und andere Dienste gestoppt.
rendegast hat geschrieben:lsof | grep delet
Danke, dass haben wir in der Tat noch nicht ausprobiert. Aber selbst wenn 2 Wochen lang Filedescriptoren von Docker Containern hängen, dürften die nicht 53 GB einnehmen. Ich werde es aber mal ausprobieren. Needrestart (als checkrestart Alternative) haben wir auch nicht nicht ausprobiert.
Soft: Bullseye AMD64, MATE Desktop. Repo's: Backports, kein Proposed, eigene Backports. Grafik: Radeon R7 360 MESA.
Hardware: Thinkstation S20, Intel X58, 16GB, Xeon W3530, BCM5755 NIC, EMU10K1 SND, SATA SSD+HDS und DVD+RW.

Antworten