# [SOLVED] Kernel benutzt extrem viel Speicher

## ChrisM87

Hallo,

seit einiger Zeit habe ich hier das Problem, dass der Kernel extrem viel Speicher verbraucht. Sobald ich mich in KDE einlogge, ist noch alles in Ordnung. Während dem Arbeiten kann ich dann aber fast zusehen, wie über wenige Minuten der Speicherverbrauch des Kernels im meinem Monitoring-Kicker-Applet auf fast die Hälfte des RAMs anwächst.

Jetzt im Moment braucht der Kernel (rot) ca. 4-mal so viel Speicher wie der ganze Userspace (blau in dem Kicker-Applet) zusammen.

Wenn ich mich dann auslogge und alles beende, sehe ich bei free immer noch 700MB als used (-/+ buffers/cache), bei ps aber keinen Prozess mit > 1% RAM-Verbrauch.

Kernel ist schon seit Wochen 22-gentoo-r2, aber das Problem tritt erst seit kurzem auf. Beim Überfliegen des emerge.log konnte ich kein problematisches Paket finden, was den Fehler verursachen könnte.

Hat jemand eine Idee, was das sein könnte oder evtl. eine Idee, wie man rausfinden kann, welcher Teil des Kernels meinen Speicher so zumüllt?

Specs:

Asus A8N-E

Athlon64 X2 3800+

2GB RAM

emerge --info:

 *Quote:*   

> Portage 2.1.2.12 (default-linux/amd64/2006.1/desktop, gcc-4.1.2, glibc-2.5-r4, 2.6.22-gentoo-r2 x86_64)
> 
> =================================================================
> 
> System uname: 2.6.22-gentoo-r2 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 3800+
> ...

 

ChrisM

----------

## AmonAmarth

also ich vermute mal das die kernel auslastung (rot) bei dir auch programme umfasst die im kernel mode laufen. es muss demnach also nicht zwangsläufig der kernel selber sein!

ähnliche effekte hatte ich mal als ich captive-ntfs benutzt hab, wobei da aber der userspace zugabellert worden ist und nicht der kernel space (wegen fuse)

berichtigt mich wenn ich falsch liege, aber meiner meinung nach könnte das genausogut ein programm sein was du erst kürzlich installiert hast (welches dann im kernel mode läuft).

fasse mal kurz zusammen was du kurz bevor die probleme auftraten so installiert hast

mfg

----------

## mv

So ein kernel memory leak (google-Stichwort!) kann extrem hässlich sein - ich hatte monatelang nach einem gesucht, bis es irgendwann in einer neuen Kernel-Version geschlossen war. Du hast immerhin das "Glück", dass das Problem wohl relativ schnell und reproduzierbar auftritt. Vielleicht findest Du in /proc/meminfo oder ggf. in /proc/slab wo Dein Speicher abbleibt. Es gibt auch Kernel-Patches (in den ck-sources enthalten), mit denen kannst Du die Speicher-Anforderungen genauer protokollieren lassen (drückt extrem auf die Geschwindigkeit, aber zum Testen...)

----------

## sschlueter

Dass der Kernel unbenutzen RAM für Buffers+Cache verwendet, ist völlig normal und auch richtig so.

----------

## mv

 *sschlueter wrote:*   

> Dass der Kernel unbenutzen RAM für Buffers+Cache verwendet, ist völlig normal und auch richtig so.

  *ChrisM87 wrote:*   

> bei free immer noch 700MB als used (-/+ buffers/cache)

 

----------

## ChrisM87

Hallo,

@AmonAmarth: Danke für die Hinweis, aber leider habe ich schon seit Wochen keine Systemtools verändert. Das ist ja gerade, was mich so stutzig macht.

 *Quote:*   

> So ein kernel memory leak (google-Stichwort!) kann extrem hässlich sein - ich hatte monatelang nach einem gesucht, bis es irgendwann in einer neuen Kernel-Version geschlossen war. Du hast immerhin das "Glück", dass das Problem wohl relativ schnell und reproduzierbar auftritt. Vielleicht findest Du in /proc/meminfo oder ggf. in /proc/slab wo Dein Speicher abbleibt. Es gibt auch Kernel-Patches (in den ck-sources enthalten), mit denen kannst Du die Speicher-Anforderungen genauer protokollieren lassen (drückt extrem auf die Geschwindigkeit, aber zum Testen...)

 

So reproduzierbar tritt es leider gar nicht auf. Jetzt ist z.B. gerade wieder alles in Ordnung, vorhin dachte ich sogar noch, mit einem anderen Kernel das Problem gelöst zu haben (hat sich leider dann falsifiziert). Jetzt habe ich aber mal eine Kopie von slabinfo gezogen und warte darauf, dass der Kernel wieder anfängt, RAM zu schlucken.

Ich melde mich dann nochmal!

 *Quote:*   

> Dass der Kernel unbenutzen RAM für Buffers+Cache verwendet, ist völlig normal und auch richtig so.

 

Nichts für ungut, aber ich bin kein Anfänger und administriere seit ein paar Jahren ca. zehn bis zwanzig Linux-Systeme mit allen möglichen Distributionen. Mal ganz davon abgesehen davon, ist es schon farblich unmöglich, Kernel-Mem im Kicker-Applet mit Swap/Buffers (grün-gelb) zu verwechseln.  :Wink: 

ChrisM

----------

## ChrisM87

Hallo,

okay, ich glaube, ich habe den schuldigen gefunden: Den Inode-Cache.

Hier eine Statistik aus Munin:

http://chrismandery.dyndns.org/statistik.png

Die Lücken kommen daher, weil der Rechner meine Zweit-Workstation ist und eigentlich nur abends, wenn überhaupt, läuft.

Hat jemand eine Idee, wie ich rauskriege, warum der Inode-Cache so groß ist bzw. der Kernel ihn nicht wieder verkleinert? Ich möchte nur nochmal betonen, dass hier nichts Besonderes läuft, nur ein KDE mit Firefox, Thunderbird, Gaim, Konversation, Akregator usw. und halt ein paar Basisdienste wie Timidity, Apache, MySQL, Tor, Privoxy und eben Munin.

ChrisM

----------

## firefly

ich habe da mal was gefunden bezüglich inode-cache

http://kerneltrap.org/node/4462

----------

## ChrisM87

Hallo,

EDIT: Danke Firefly für die Antwort!

Okay, das Rätsel ist aufgelöst:

Was so viel Speicher verbraucht hat, war tatsächlich der inode und dentry (directory entry) Cache, der in Folge von updatedb, emerge --sync oder ähnlichen Dingen auf astronomische Höhen über 600k Einträge anwuchs.

Was ich allerdings nicht wusste und das Kicker-Applet oder free auch nicht verraten: Der Speicher ist nicht verbraucht oder in aktiver Benutzung, sondern wie der Name schon sagt, nur ein Cache, der bei Bedarf auch wieder geshrinkt wird. Dieser Bedarf entsteht, wenn Userland-Programme Speicher brauchen oder mit der Zeit mit IO-Operationen neue Daten für den IO-Cache anfallen (der wird dann vergrößert). Solange aber bleibt dieser Speicher in Benutzung des Kernels und wird auch so ausgewiesen.

Dieses Verhalten, also wie groß die Präferenz des Kernels ist, den inode Cache zu Gunsten des IO Caches/Buffers zu shrinken, kann man übrigens über /proc/sys/vm/vfs_cache_pressure feintunen. Der Default von 100 scheint aber ganz gut zu arbeiten.

Ich überlege jetzt nur noch, warum mir das "Problem" vorher noch nie aufgefallen ist. Vielleicht liegt es daran, dass ich bis vor einigen Tagen fast immer MP3s von der Platte gehört habe (= IO!) und die letzten Tage Webradio höre. So entsteht weniger IO-Traffic und der inode-Cache wird nicht sofort wieder geshrinkt.

Irreführend finde ich dann nur das Verhalten von free, dass den inode Cache nicht separat nochmal bei +/- Caches abzieht, aber mir ist klar, dass free die Werte, die es anzeigt, so direkt vom Kernel erhält und es wohl einige Leute verwirren würde, wenn da nochmal was mit /proc/slabinfo verrechnet werden würde.

Ich stelle den Thread dann mal auf SOLVED.

ChrisM

----------

## sschlueter

Das ist doch mal ein interessanter Thread. Tut mir leid, dass ich dein ursprüngliches Posting nicht richtig gelesen hatte, wollte dich nicht beleidigen.

Ich habe aber doch noch eine Frage zu der Sache: Kann man eigentlich den Kernel-Speicher über die free-Ausgabe berechnen? Ich denke, nein, aber ich wollte doch mal nachfragen. atop scheint es als Feld "slab" anzuzeigen. Ist das dasselbe, was das Kicker-Applet rot einfärbt?

----------

## ChrisM87

Hi,

nein, aus free kannst du den Speicher nicht berechnen.

Aber in /proc/meminfo siehst du ihn:

 *Quote:*   

> Slab:           734820 kB
> 
> SReclaimable:   706808 kB

 

Die zweite Zahl gibt wohl an, wieviel bei andersweitigem Bedarf kurzfristig wieder freigegeben werden kann, aber auf die Idee bin ich vorher nicht gekommen.  :Wink: 

Die 740MB scheinen auf jeden Fall auch das zu sein, was der Kicker rot einfärbt und auch das, was atop anzeigt.

ChrisM

----------

