Linux-Raumsituation (32-Bit-Kernel)

Question 1

Ein rigoroser Ansatz wäre allerdings die Aktualisierung auf ein 64-Bit-Betriebssystem (hier handelt es sich um 32 Bit), da die Zonen anders angeordnet sind.

OK, hier werde ich versuchen zu beantworten, warum Sie hier ein OOM erlebt haben. Dabei spielen mehrere Faktoren eine Rolle.

Die Bestellgröße der Anfrage und wie der Kernel bestimmte Bestellgrößen behandelt.
Die ausgewählte Zone.
Die Wasserzeichen, die diese Zone verwendet.
Fragmentierung in der Zone.

Wenn Sie sich den OOM selbst ansehen, ist eindeutig viel freier Speicher verfügbar, aber der OOM-Killer wurde aufgerufen? Warum?

Die Auftragsgröße der Anfrage und wie der Kernel bestimmte Auftragsgrößen behandelt

Der Kernel weist den Speicher nach Reihenfolge zu. Eine „Reihenfolge“ ist ein Bereich des zusammenhängenden RAM, der erfüllt sein muss, damit die Anforderung funktioniert. Die Reihenfolgen werden mithilfe des Algorithmus nach Größenordnungen (daher der Name Reihenfolge) angeordnet 2^(ORDER + 12). Reihenfolge 0 ist also 4096, Reihenfolge 1 ist 8192, Reihenfolge 2 ist 16384 und so weiter und so fort.

Der Kernel hat einen fest codierten Wert für das, was als „hohe Ordnung“ (> PAGE_ALLOC_COSTLY_ORDER) gilt. Dies ist Ordnung 4 und höher (64 KB oder höher ist eine hohe Ordnung).

Hohe Ordnungen werden für Seitenzuweisungen anders erfüllt als niedrige Ordnungen. Eine hohe Ordnungszuweisung wird bei modernen Kerneln erfüllt, wenn sie den Speicher nicht nutzen kann.

Versuchen Sie, die Speicherkomprimierungsroutine auszuführen, um den Speicher zu defragmentieren.
NiemalsRufen Sie OOM-Killer auf, um die Anfrage zu erfüllen.

Ihre Bestellgröße finden Sie hier

Dec 27 09:19:05 2013 kernel: : [277622.359064] squid invoked oom-killer: gfp_mask=0x42d0, order=3, oom_score_adj=0

Auftrag 3 ist der höchste der niederwertigsten Aufträge und (wie Sie sehen) ruft OOM-Killer auf, um ihn zu erfüllen.

Beachten Sie, dass die meisten Userspace-Zuweisungen keine High-Order-Anfragen verwenden. Normalerweise ist es der Kernel, der zusammenhängende Speicherbereiche benötigt. Eine Ausnahme hiervon kann sein, wenn der Userspace große Seiten verwendet – das ist hier jedoch nicht der Fall.

In Ihrem Fall wird die Zuweisung der Reihenfolge 3 vom Kernel aufgerufen, der ein Paket in den Netzwerkstapel einreihen möchte – wofür eine Zuweisung von 32 KB erforderlich ist.

Die ausgewählte Zone.

Der Kernel teilt Ihre Speicherbereiche in Zonen auf. Diese Aufteilung erfolgt, weil auf x86 bestimmte Speicherbereiche nur von bestimmter Hardware adressiert werden können. Ältere Hardware kann beispielsweise nur Speicher in der Zone „DMA“ adressieren. Wenn wir Speicher zuweisen möchten, wird zuerst eine Zone ausgewählt undnurDer freie Speicher dieser Zone wird bei der Zuweisungsentscheidung berücksichtigt.

Obwohl ich mich mit dem Algorithmus zur Zonenauswahl nicht ganz auskenne, besteht der typische Anwendungsfall nie darin, aus DMA zuzuweisen, sondern normalerweise die niedrigste adressierbare Zone auszuwählen, die die Anforderung erfüllen kann.

Während des OOM werden viele Zoneninformationen ausgespuckt, die auch aus entnommen werden können /proc/zoneinfo.

Dec 27 09:19:05 2013 kernel: : [277622.359382] DMA free:2332kB min:36kB low:44kB high:52kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15968kB managed:6960kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:8kB slab_unreclaimable:288kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
Dec 27 09:19:05 2013 kernel: : [277622.359393] Normal free:114488kB min:3044kB low:3804kB high:4564kB active_anon:0kB inactive_anon:0kB active_file:252kB inactive_file:256kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:894968kB managed:587540kB mlocked:0kB dirty:0kB writeback:0kB mapped:4kB shmem:0kB slab_reclaimable:117712kB slab_unreclaimable:138616kB kernel_stack:11976kB pagetables:0kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:982 all_unreclaimable? yes
Dec 27 09:19:05 2013 kernel: : [277622.359404] HighMem free:27530668kB min:512kB low:48272kB high:96036kB active_anon:2634060kB inactive_anon:217596kB active_file:4688452kB inactive_file:1294168kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:36828872kB managed:36828872kB mlocked:0kB dirty:0kB writeback:0kB mapped:183132kB shmem:39400kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:430856kB unstable:0kB bounce:367564104kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no

Die Zonen, die Sie haben, DMA, Normal und HighMem, weisen auf eine 32-Bit-Plattform hin, da die HighMem-Zone auf 64-Bit nicht vorhanden ist. Außerdem wird auf 64-Bit-Systemen Normal auf 4 GB und mehr abgebildet, während es auf 32-Bit bis zu 896 MB abbildet (obwohl der Kernel in Ihrem Fall nur einen kleineren Teil als diesen verwaltet:- meldet managed:587540kB).

Es ist möglich, festzustellen, woher diese Zuweisung kam, indem man sich die erste Zeile noch einmal ansieht gfp_mask=0x42d0. Sie sagt uns, welche Art von Zuweisung vorgenommen wurde. Das letzte Byte (0) sagt uns, dass dies eine Zuweisung aus der normalen Zone ist. Die gfp-Bedeutungen befinden sich ininclude/linux/gfp.h.

Die Wasserzeichen, die diese Zone verwendet.

Wenn der Speicher knapp wird, werden die Aktionen zur Wiederherstellung durch das Wasserzeichen angegeben. Sie werden hier angezeigt: min:3044kB low:3804kB high:4564kB. Wenn der freie Speicher „niedrig“ erreicht, wird so lange geswapt, bis wir den „hohen“ Schwellenwert überschreiten. Wenn der Speicher „min“ erreicht, müssen wir Dinge löschen, um über den OOM-Killer Speicher freizugeben.

Fragmentierung in der Zone.

Um zu sehen, ob eine Anforderung für eine bestimmte Speicherbestellung erfüllt werden kann, berechnet der Kernel, wie viele freie Seiten und wie viele für jede Bestellung verfügbar sind. Dies ist in nachlesbar /proc/buddyinfo. OOM-Killer-Berichte geben zusätzlich auch die Buddyinfo aus, wie hier zu sehen ist:

Normal: 5360*4kB (UEM) 3667*8kB (UEM) 3964*16kB (UEMR) 13*32kB (MR) 0*64kB 1*128kB (R) 1*256kB (R) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 115000kB

Damit eine Speicherzuordnung erfüllt werden kann,mussEs muss freier Speicher in der angeforderten Ordnungsgröße oder in einer höheren Zuordnung verfügbar sein. Wenn Sie sehr viele freie Daten in den niedrigen Ordnungen und keine in den höheren Ordnungen haben, bedeutet dies, dass Ihr Speicher fragmentiert ist. Wenn Sie eine sehr hohe Ordnungszuordnung erhalten, ist es möglich (selbst bei viel freiem Speicher), dass diese nicht erfüllt wird, weil keine Seiten mit höherer Ordnung verfügbar sind. Der Kernel kann den Speicher defragmentieren (dies wird als Speicherkomprimierung bezeichnet), indem er viele Seiten mit niedriger Ordnung verschiebt, sodass sie keine Lücken im adressierbaren RAM-Speicher hinterlassen.

OOM-Killer wurde aufgerufen? Warum?

Wenn wir diese Dinge berücksichtigen, können wir Folgendes sagen:

Es wurde eine zusammenhängende Zuweisung von 32 kB versucht. Aus der normalen Zone.
In der ausgewählten Zone war ausreichend freier Speicher vorhanden.
Es waren Speicher der Reihenfolge 3, 5 und 6 verfügbar13*32kB (MR) 1*128kB (R) 1*256kB (R)

Wenn es alsoWarfreier Speicher, andere Aufträgekönnteder Anfrage nachkommen. Was ist passiert?

Nun, bei der Zuweisung aus einer Reihenfolge geht es um mehr als nur die Überprüfung des für diese oder eine höhere Reihenfolge verfügbaren freien Speichers. Der Kernel zieht effektiv Speicher aller niedrigeren Reihenfolgen von der gesamten freien Zeile ab und führt dann die Mindestwasserzeichenprüfung für den verbleibenden Speicher durch.

In Ihrem Fall müssen wir unseren freien Speicher für die Zone überprüfen.

115000 - (5360*4) - (3667*8) - (3964*16) = 800

Diese Menge an freiem Speicher wird mit dem minGrenzwert von 3044 verglichen. Technisch gesehen haben Sie also keinen freien Speicher mehr, um die angeforderte Zuweisung durchzuführen. Und deshalb haben Sie OOM-Killer aufgerufen.

Festsetzung

Es gibt zwei Lösungen. Ein Upgrade auf 64 Bit ändert Ihre Zonenpartitionierung so, dass „Normal“ 4 GB bis 36 GB beträgt, sodass Sie Ihre Speicherzuweisung nicht „standardmäßig“ in einer Zone vornehmen, die so stark fragmentiert werden kann. Das Problem wird nicht dadurch behoben, dass Sie mehr adressierbaren Speicher haben (weil Sie bereits PAE verwenden), sondern nur dadurch, dass die Zone, aus der Sie auswählen, mehr adressierbaren Speicher hat.

Die zweite Möglichkeit (die ich nie getestet habe) besteht darin, zu versuchen, den Kernel dazu zu bringen, Ihren Speicher stärker zu komprimieren.

Wenn Sie den Wert von vm.extfrag_threshold500 auf 100 ändern, wird der Speicher wahrscheinlich komprimiert, um eine höherwertige Zuordnung zu ermöglichen. Allerdings habe ich diesen Wert noch nie verändert – es hängt auch von Ihrem Fragmentierungsindex ab, der in verfügbar ist /sys/kernel/debug/extfrag/extfrag_index. Ich habe im Moment keine Box mit einem ausreichend neuen Kernel, um zu sehen, was das zeigt, um mehr als das zu bieten.

Alternativ können Sie eine Art Cron-Job ausführen (das ist furchtbar, furchtbar hässlich), um den Speicher manuell zu komprimieren, indem Sie in schreiben /proc/sys/vm/compact_memory.

Ehrlich gesagt glaube ich jedoch nicht, dass es wirklich eine Möglichkeit gibt, das System so zu optimieren, dass dieses Problem vermieden wird – es liegt in der Natur des Speicherallokators, auf diese Weise zu arbeiten. Die einzige grundsätzlich lösbare Lösung besteht wahrscheinlich darin, die Architektur der von Ihnen verwendeten Plattform zu ändern.

Answer

Ein rigoroser Ansatz wäre allerdings die Aktualisierung auf ein 64-Bit-Betriebssystem (hier handelt es sich um 32 Bit), da die Zonen anders angeordnet sind.

OK, hier werde ich versuchen zu beantworten, warum Sie hier ein OOM erlebt haben. Dabei spielen mehrere Faktoren eine Rolle.

Die Bestellgröße der Anfrage und wie der Kernel bestimmte Bestellgrößen behandelt.
Die ausgewählte Zone.
Die Wasserzeichen, die diese Zone verwendet.
Fragmentierung in der Zone.

Wenn Sie sich den OOM selbst ansehen, ist eindeutig viel freier Speicher verfügbar, aber der OOM-Killer wurde aufgerufen? Warum?

Die Auftragsgröße der Anfrage und wie der Kernel bestimmte Auftragsgrößen behandelt

Der Kernel weist den Speicher nach Reihenfolge zu. Eine „Reihenfolge“ ist ein Bereich des zusammenhängenden RAM, der erfüllt sein muss, damit die Anforderung funktioniert. Die Reihenfolgen werden mithilfe des Algorithmus nach Größenordnungen (daher der Name Reihenfolge) angeordnet 2^(ORDER + 12). Reihenfolge 0 ist also 4096, Reihenfolge 1 ist 8192, Reihenfolge 2 ist 16384 und so weiter und so fort.

Der Kernel hat einen fest codierten Wert für das, was als „hohe Ordnung“ (> PAGE_ALLOC_COSTLY_ORDER) gilt. Dies ist Ordnung 4 und höher (64 KB oder höher ist eine hohe Ordnung).

Hohe Ordnungen werden für Seitenzuweisungen anders erfüllt als niedrige Ordnungen. Eine hohe Ordnungszuweisung wird bei modernen Kerneln erfüllt, wenn sie den Speicher nicht nutzen kann.

Versuchen Sie, die Speicherkomprimierungsroutine auszuführen, um den Speicher zu defragmentieren.
NiemalsRufen Sie OOM-Killer auf, um die Anfrage zu erfüllen.

Ihre Bestellgröße finden Sie hier

Dec 27 09:19:05 2013 kernel: : [277622.359064] squid invoked oom-killer: gfp_mask=0x42d0, order=3, oom_score_adj=0

Auftrag 3 ist der höchste der niederwertigsten Aufträge und (wie Sie sehen) ruft OOM-Killer auf, um ihn zu erfüllen.

Beachten Sie, dass die meisten Userspace-Zuweisungen keine High-Order-Anfragen verwenden. Normalerweise ist es der Kernel, der zusammenhängende Speicherbereiche benötigt. Eine Ausnahme hiervon kann sein, wenn der Userspace große Seiten verwendet – das ist hier jedoch nicht der Fall.

In Ihrem Fall wird die Zuweisung der Reihenfolge 3 vom Kernel aufgerufen, der ein Paket in den Netzwerkstapel einreihen möchte – wofür eine Zuweisung von 32 KB erforderlich ist.

Die ausgewählte Zone.

Der Kernel teilt Ihre Speicherbereiche in Zonen auf. Diese Aufteilung erfolgt, weil auf x86 bestimmte Speicherbereiche nur von bestimmter Hardware adressiert werden können. Ältere Hardware kann beispielsweise nur Speicher in der Zone „DMA“ adressieren. Wenn wir Speicher zuweisen möchten, wird zuerst eine Zone ausgewählt undnurDer freie Speicher dieser Zone wird bei der Zuweisungsentscheidung berücksichtigt.

Obwohl ich mich mit dem Algorithmus zur Zonenauswahl nicht ganz auskenne, besteht der typische Anwendungsfall nie darin, aus DMA zuzuweisen, sondern normalerweise die niedrigste adressierbare Zone auszuwählen, die die Anforderung erfüllen kann.

Während des OOM werden viele Zoneninformationen ausgespuckt, die auch aus entnommen werden können /proc/zoneinfo.

Dec 27 09:19:05 2013 kernel: : [277622.359382] DMA free:2332kB min:36kB low:44kB high:52kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15968kB managed:6960kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:8kB slab_unreclaimable:288kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
Dec 27 09:19:05 2013 kernel: : [277622.359393] Normal free:114488kB min:3044kB low:3804kB high:4564kB active_anon:0kB inactive_anon:0kB active_file:252kB inactive_file:256kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:894968kB managed:587540kB mlocked:0kB dirty:0kB writeback:0kB mapped:4kB shmem:0kB slab_reclaimable:117712kB slab_unreclaimable:138616kB kernel_stack:11976kB pagetables:0kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:982 all_unreclaimable? yes
Dec 27 09:19:05 2013 kernel: : [277622.359404] HighMem free:27530668kB min:512kB low:48272kB high:96036kB active_anon:2634060kB inactive_anon:217596kB active_file:4688452kB inactive_file:1294168kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:36828872kB managed:36828872kB mlocked:0kB dirty:0kB writeback:0kB mapped:183132kB shmem:39400kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:430856kB unstable:0kB bounce:367564104kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no

Die Zonen, die Sie haben, DMA, Normal und HighMem, weisen auf eine 32-Bit-Plattform hin, da die HighMem-Zone auf 64-Bit nicht vorhanden ist. Außerdem wird auf 64-Bit-Systemen Normal auf 4 GB und mehr abgebildet, während es auf 32-Bit bis zu 896 MB abbildet (obwohl der Kernel in Ihrem Fall nur einen kleineren Teil als diesen verwaltet:- meldet managed:587540kB).

Es ist möglich, festzustellen, woher diese Zuweisung kam, indem man sich die erste Zeile noch einmal ansieht gfp_mask=0x42d0. Sie sagt uns, welche Art von Zuweisung vorgenommen wurde. Das letzte Byte (0) sagt uns, dass dies eine Zuweisung aus der normalen Zone ist. Die gfp-Bedeutungen befinden sich ininclude/linux/gfp.h.

Die Wasserzeichen, die diese Zone verwendet.

Wenn der Speicher knapp wird, werden die Aktionen zur Wiederherstellung durch das Wasserzeichen angegeben. Sie werden hier angezeigt: min:3044kB low:3804kB high:4564kB. Wenn der freie Speicher „niedrig“ erreicht, wird so lange geswapt, bis wir den „hohen“ Schwellenwert überschreiten. Wenn der Speicher „min“ erreicht, müssen wir Dinge löschen, um über den OOM-Killer Speicher freizugeben.

Fragmentierung in der Zone.

Um zu sehen, ob eine Anforderung für eine bestimmte Speicherbestellung erfüllt werden kann, berechnet der Kernel, wie viele freie Seiten und wie viele für jede Bestellung verfügbar sind. Dies ist in nachlesbar /proc/buddyinfo. OOM-Killer-Berichte geben zusätzlich auch die Buddyinfo aus, wie hier zu sehen ist:

Normal: 5360*4kB (UEM) 3667*8kB (UEM) 3964*16kB (UEMR) 13*32kB (MR) 0*64kB 1*128kB (R) 1*256kB (R) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 115000kB

Damit eine Speicherzuordnung erfüllt werden kann,mussEs muss freier Speicher in der angeforderten Ordnungsgröße oder in einer höheren Zuordnung verfügbar sein. Wenn Sie sehr viele freie Daten in den niedrigen Ordnungen und keine in den höheren Ordnungen haben, bedeutet dies, dass Ihr Speicher fragmentiert ist. Wenn Sie eine sehr hohe Ordnungszuordnung erhalten, ist es möglich (selbst bei viel freiem Speicher), dass diese nicht erfüllt wird, weil keine Seiten mit höherer Ordnung verfügbar sind. Der Kernel kann den Speicher defragmentieren (dies wird als Speicherkomprimierung bezeichnet), indem er viele Seiten mit niedriger Ordnung verschiebt, sodass sie keine Lücken im adressierbaren RAM-Speicher hinterlassen.

OOM-Killer wurde aufgerufen? Warum?

Wenn wir diese Dinge berücksichtigen, können wir Folgendes sagen:

Es wurde eine zusammenhängende Zuweisung von 32 kB versucht. Aus der normalen Zone.
In der ausgewählten Zone war ausreichend freier Speicher vorhanden.
Es waren Speicher der Reihenfolge 3, 5 und 6 verfügbar13*32kB (MR) 1*128kB (R) 1*256kB (R)

Wenn es alsoWarfreier Speicher, andere Aufträgekönnteder Anfrage nachkommen. Was ist passiert?

Nun, bei der Zuweisung aus einer Reihenfolge geht es um mehr als nur die Überprüfung des für diese oder eine höhere Reihenfolge verfügbaren freien Speichers. Der Kernel zieht effektiv Speicher aller niedrigeren Reihenfolgen von der gesamten freien Zeile ab und führt dann die Mindestwasserzeichenprüfung für den verbleibenden Speicher durch.

In Ihrem Fall müssen wir unseren freien Speicher für die Zone überprüfen.

115000 - (5360*4) - (3667*8) - (3964*16) = 800

Diese Menge an freiem Speicher wird mit dem minGrenzwert von 3044 verglichen. Technisch gesehen haben Sie also keinen freien Speicher mehr, um die angeforderte Zuweisung durchzuführen. Und deshalb haben Sie OOM-Killer aufgerufen.

Festsetzung

Es gibt zwei Lösungen. Ein Upgrade auf 64 Bit ändert Ihre Zonenpartitionierung so, dass „Normal“ 4 GB bis 36 GB beträgt, sodass Sie Ihre Speicherzuweisung nicht „standardmäßig“ in einer Zone vornehmen, die so stark fragmentiert werden kann. Das Problem wird nicht dadurch behoben, dass Sie mehr adressierbaren Speicher haben (weil Sie bereits PAE verwenden), sondern nur dadurch, dass die Zone, aus der Sie auswählen, mehr adressierbaren Speicher hat.

Die zweite Möglichkeit (die ich nie getestet habe) besteht darin, zu versuchen, den Kernel dazu zu bringen, Ihren Speicher stärker zu komprimieren.

Wenn Sie den Wert von vm.extfrag_threshold500 auf 100 ändern, wird der Speicher wahrscheinlich komprimiert, um eine höherwertige Zuordnung zu ermöglichen. Allerdings habe ich diesen Wert noch nie verändert – es hängt auch von Ihrem Fragmentierungsindex ab, der in verfügbar ist /sys/kernel/debug/extfrag/extfrag_index. Ich habe im Moment keine Box mit einem ausreichend neuen Kernel, um zu sehen, was das zeigt, um mehr als das zu bieten.

Alternativ können Sie eine Art Cron-Job ausführen (das ist furchtbar, furchtbar hässlich), um den Speicher manuell zu komprimieren, indem Sie in schreiben /proc/sys/vm/compact_memory.

Ehrlich gesagt glaube ich jedoch nicht, dass es wirklich eine Möglichkeit gibt, das System so zu optimieren, dass dieses Problem vermieden wird – es liegt in der Natur des Speicherallokators, auf diese Weise zu arbeiten. Die einzige grundsätzlich lösbare Lösung besteht wahrscheinlich darin, die Architektur der von Ihnen verwendeten Plattform zu ändern.

Question 2

Zu Beginn: Sie solltenWirklichEntscheiden Sie sich für ein 64-Bit-Betriebssystem. Haben Sie einen guten Grund, hier bei 32-Bit zu bleiben?

Es ist schwierig, dieses Problem zu diagnostizieren, ohne sich das System genauer anzusehen, vorzugsweise zu dem Zeitpunkt, an dem es ausfällt. Daher ist mein (kurzer) Beitrag mehr oder weniger allgemein auf Speicherprobleme bei 32-Bit-Systemen ausgerichtet. Habe ich erwähnt, dass die Umstellung auf 64-Bit das Problem lösen würde?

Ihr Problem ist dreifach.

Erstens ist der Adressraum pro Prozess sogar auf einem PAE-Kernel auf 4 GiB[1] begrenzt. Das bedeutet, dass Ihre Squid-Instanz nie mehr als 4 GiB RAM pro Prozess verbrauchen kann. Ich kenne mich mit Squid nicht so gut aus, aber wenn dies Ihr Hauptproxyserver ist, reicht das möglicherweise sowieso nicht aus.

Zweitens wird auf einem 32-Bit-System mit riesigen Mengen an RAM viel Speicher in der sogenannten „ZONE_NORMAL“ verwendet, um Datenstrukturen zu speichern, die für die Verwendung von Speicher in ZONE_HIGHMEM erforderlich sind. Diese Datenstrukturen können nicht selbst in ZONE_HIGHMEM verschoben werden, da der Speicher, den der Kernel für seine eigenen Zwecke verwendet, immer in ZONE_NORMAL (also in den ersten 1GiB-etwa) liegen muss. Je mehr Speicher Sie in ZONE_HIGHMEM haben (in Ihrem Fall viel), desto problematischer wird dies, da der Kernel dann immer mehr Speicher aus ZONE_NORMAL benötigt, um ZONE_HIGHMEM zu verwalten. Wenn der freie Speicher in ZONE_NORMAL knapp wird, kann Ihr System bei einigen Aufgaben versagen, da ZONE_NORMAL der Ort ist, an dem einvielauf einem 32-Bit-System passiert so einiges. Alle mit dem Kernel verbundenen Speicheroperationen zum Beispiel ;)

Drittens: Selbst wenn in ZONE_NORMAL noch etwas Speicher übrig ist (ich habe Ihre Protokolle nicht im Detail durchgesehen), erfordern einige Speicheroperationen unfragmentierten Speicher. Wenn beispielsweise Ihr gesamter Speicher in sehr kleine Teile fragmentiert ist, schlagen einige Operationen fehl, die mehr als das benötigen. [3] Ein kurzer Blick auf Ihre Protokolle zeigt eine ziemlich erhebliche Fragmentierung in ZONE_DMA und ZONE_NORMAL.

Bearbeiten: Die obige Antwort von Mlfe enthält eine hervorragende Erklärung, wie dies im Detail funktioniert.

Noch einmal: Auf einem 64-Bit-System befindet sich der gesamte Speicher in ZONE_NORMAL. Auf 64-Bit-Systemen gibt es keine HIGHMEM-Zone. Problem gelöst.

Edit: Du könntest hier [4] nachschauen, ob du oom-killer anweisen kannst, deine wichtigen Prozesse in Ruhe zu lassen. Das wird zwar nicht alles lösen (wenn überhaupt etwas), aber einen Versuch könnte es wert sein.

[1]http://en.wikipedia.org/wiki/Physical_address_extension#Design

[2]http://www.redhat.com/archives/rhelv5-list/2008-September/msg00237.htmlUndhttps://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Tuning_and_Optimizing_Red_Hat_Enterprise_Linux_for_Oracle_9i_and_10g_Databases/sect-Oracle_9i_and_10g_Tuning_Guide-Hardware_Architectures_and_Linux_Kernels-a32_bit_Architecture_and_the_hugemem_Kernel.html

[3]http://bl0rg.krunch.be/oom-frag.html

[4]http://lwn.net/Articles/317814/

Answer

Zu Beginn: Sie solltenWirklichEntscheiden Sie sich für ein 64-Bit-Betriebssystem. Haben Sie einen guten Grund, hier bei 32-Bit zu bleiben?

Es ist schwierig, dieses Problem zu diagnostizieren, ohne sich das System genauer anzusehen, vorzugsweise zu dem Zeitpunkt, an dem es ausfällt. Daher ist mein (kurzer) Beitrag mehr oder weniger allgemein auf Speicherprobleme bei 32-Bit-Systemen ausgerichtet. Habe ich erwähnt, dass die Umstellung auf 64-Bit das Problem lösen würde?

Ihr Problem ist dreifach.

Erstens ist der Adressraum pro Prozess sogar auf einem PAE-Kernel auf 4 GiB[1] begrenzt. Das bedeutet, dass Ihre Squid-Instanz nie mehr als 4 GiB RAM pro Prozess verbrauchen kann. Ich kenne mich mit Squid nicht so gut aus, aber wenn dies Ihr Hauptproxyserver ist, reicht das möglicherweise sowieso nicht aus.

Zweitens wird auf einem 32-Bit-System mit riesigen Mengen an RAM viel Speicher in der sogenannten „ZONE_NORMAL“ verwendet, um Datenstrukturen zu speichern, die für die Verwendung von Speicher in ZONE_HIGHMEM erforderlich sind. Diese Datenstrukturen können nicht selbst in ZONE_HIGHMEM verschoben werden, da der Speicher, den der Kernel für seine eigenen Zwecke verwendet, immer in ZONE_NORMAL (also in den ersten 1GiB-etwa) liegen muss. Je mehr Speicher Sie in ZONE_HIGHMEM haben (in Ihrem Fall viel), desto problematischer wird dies, da der Kernel dann immer mehr Speicher aus ZONE_NORMAL benötigt, um ZONE_HIGHMEM zu verwalten. Wenn der freie Speicher in ZONE_NORMAL knapp wird, kann Ihr System bei einigen Aufgaben versagen, da ZONE_NORMAL der Ort ist, an dem einvielauf einem 32-Bit-System passiert so einiges. Alle mit dem Kernel verbundenen Speicheroperationen zum Beispiel ;)

Drittens: Selbst wenn in ZONE_NORMAL noch etwas Speicher übrig ist (ich habe Ihre Protokolle nicht im Detail durchgesehen), erfordern einige Speicheroperationen unfragmentierten Speicher. Wenn beispielsweise Ihr gesamter Speicher in sehr kleine Teile fragmentiert ist, schlagen einige Operationen fehl, die mehr als das benötigen. [3] Ein kurzer Blick auf Ihre Protokolle zeigt eine ziemlich erhebliche Fragmentierung in ZONE_DMA und ZONE_NORMAL.

Bearbeiten: Die obige Antwort von Mlfe enthält eine hervorragende Erklärung, wie dies im Detail funktioniert.

Noch einmal: Auf einem 64-Bit-System befindet sich der gesamte Speicher in ZONE_NORMAL. Auf 64-Bit-Systemen gibt es keine HIGHMEM-Zone. Problem gelöst.

Edit: Du könntest hier [4] nachschauen, ob du oom-killer anweisen kannst, deine wichtigen Prozesse in Ruhe zu lassen. Das wird zwar nicht alles lösen (wenn überhaupt etwas), aber einen Versuch könnte es wert sein.

[1]http://en.wikipedia.org/wiki/Physical_address_extension#Design

[2]http://www.redhat.com/archives/rhelv5-list/2008-September/msg00237.htmlUndhttps://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Tuning_and_Optimizing_Red_Hat_Enterprise_Linux_for_Oracle_9i_and_10g_Databases/sect-Oracle_9i_and_10g_Tuning_Guide-Hardware_Architectures_and_Linux_Kernels-a32_bit_Architecture_and_the_hugemem_Kernel.html

[3]http://bl0rg.krunch.be/oom-frag.html

[4]http://lwn.net/Articles/317814/

Question 3

@MIfe hat bereits bereitgestelltausgezeichneter Bericht über die Handhabung von Speicherzuweisungen im Kernelund bietet Ihnen auch passende Lösungen, wie die Umstellung auf ein 64-Bit-Betriebssystem und fiese Hacks wie die manuelle Speicherkomprimierung über /proc/sys/vm/compact_memoryin cron.

Meine 2 Cents wären ein weiterer Workaround, der Ihnen vielleicht helfen könnte:
Mir ist aufgefallen, dass Sie tcp_tso_segmentin Ihrem Kernel-Backtrace Folgendes haben. Gehen Sie also wie folgt vor:

# ethtool -K ethX tso off gso off lro off

kann den Druck verringern, mmindem man es zwingt, niedrigere Ordnungen zu verwenden.

PS. Eine Liste aller Offloads erhalten Sie über# ethtool -k ethX

Answer

@MIfe hat bereits bereitgestelltausgezeichneter Bericht über die Handhabung von Speicherzuweisungen im Kernelund bietet Ihnen auch passende Lösungen, wie die Umstellung auf ein 64-Bit-Betriebssystem und fiese Hacks wie die manuelle Speicherkomprimierung über /proc/sys/vm/compact_memoryin cron.

Meine 2 Cents wären ein weiterer Workaround, der Ihnen vielleicht helfen könnte:
Mir ist aufgefallen, dass Sie tcp_tso_segmentin Ihrem Kernel-Backtrace Folgendes haben. Gehen Sie also wie folgt vor:

# ethtool -K ethX tso off gso off lro off

kann den Druck verringern, mmindem man es zwingt, niedrigere Ordnungen zu verwenden.

PS. Eine Liste aller Offloads erhalten Sie über# ethtool -k ethX

Question 4

Die Panik entsteht, weil das sysctl „vm.panic_on_oom = 1“ gesetzt ist – die Idee ist, dass ein Neustart des Systems es in einen vernünftigen Zustand zurückversetzt. Sie können dies in sysctl.conf ändern.

Ganz oben steht „Squid hat oom killer aufgerufen“. Sie sollten Ihre Squid-Konfiguration und die maximale Speichernutzung überprüfen (oder einfach auf ein 64-Bit-Betriebssystem umsteigen).

/proc/meminfo zeigt die hohe Speicherzone in Verwendung an, Sie verwenden also einen 32-Bit-Kernel mit 36 GB Speicher. Sie können auch sehen, dass der Kernel in der normalen Zone 982 Seiten erfolglos gescannt hat, um den Speicherbedarf von Squid zu decken:

pages_scanned:982 all_unreclaimable? yes

Answer

Die Panik entsteht, weil das sysctl „vm.panic_on_oom = 1“ gesetzt ist – die Idee ist, dass ein Neustart des Systems es in einen vernünftigen Zustand zurückversetzt. Sie können dies in sysctl.conf ändern.

Ganz oben steht „Squid hat oom killer aufgerufen“. Sie sollten Ihre Squid-Konfiguration und die maximale Speichernutzung überprüfen (oder einfach auf ein 64-Bit-Betriebssystem umsteigen).

/proc/meminfo zeigt die hohe Speicherzone in Verwendung an, Sie verwenden also einen 32-Bit-Kernel mit 36 GB Speicher. Sie können auch sehen, dass der Kernel in der normalen Zone 982 Seiten erfolglos gescannt hat, um den Speicherbedarf von Squid zu decken:

pages_scanned:982 all_unreclaimable? yes

Linux-Raumsituation (32-Bit-Kernel)

Antwort1

Die Auftragsgröße der Anfrage und wie der Kernel bestimmte Auftragsgrößen behandelt

Die ausgewählte Zone.

Die Wasserzeichen, die diese Zone verwendet.

Fragmentierung in der Zone.

OOM-Killer wurde aufgerufen? Warum?

Festsetzung

Antwort2

Antwort3

Antwort4

verwandte Informationen