Moin,
eine Kunde von uns hat eine Applikation die ganz schön viel RAM braucht (so 80GB) auf RH 6.x. Wenn er diese stoppt kann sie anschließend nicht wieder korrekt gestartet werden. Er hat heraus gefunden, daß man den Cache vom OS vorher explizit leeren kann und dann fährt die Applikation wieder hoch.
echo 3 > /proc/sys/vm/drop_caches .
Laut kernel-Doku: sysctl/vm.txt
<snip> drop_caches
Writing to this will cause the kernel to drop clean caches, dentries and inodes from memory, causing that memory to become free.
To free pagecache: echo 1 > /proc/sys/vm/drop_caches To free dentries and inodes: echo 2 > /proc/sys/vm/drop_caches To free pagecache, dentries and inodes: echo 3 > /proc/sys/vm/drop_caches
As this is a non-destructive operation and dirty objects are not freeable, the user should run `sync' first. <snap>
wird hier nur der Cache gelöscht. Dies sollte aus meiner Sicht unnötig sein, da der Cache (auch der belegte) jederzeit frei gegeben wird.
Kernelbug? Oder blöde race condition?
H.
Hi
vielleicht hat ein schlauer "Entwickler" eine Prüfroutine drin die checkt ob genügent RAM frei ist.
Ansich sollte es keine Probleme geben Chaches wieder zuverwenden, warum es nur geht wenn man alles löscht.
Vielleicht ist es ein Kernelkäfer möglicherweise aber auch ein Hardwarefehler der deshalb auftritt das wenn Cache nicht gelehrt wird, ein kaputter Bereich genommen wird.
Andreas
Hilmar Preusse hille42@web.de schrieb am 23:20 Sonntag, 19.Januar 2014:
Moin,
eine Kunde von uns hat eine Applikation die ganz schön viel RAM braucht (so 80GB) auf RH 6.x. Wenn er diese stoppt kann sie anschließend nicht wieder korrekt gestartet werden. Er hat heraus gefunden, daß man den Cache vom OS vorher explizit leeren kann und dann fährt die Applikation wieder hoch.
echo 3 > /proc/sys/vm/drop_caches .
Laut kernel-Doku: sysctl/vm.txt
<snip> drop_caches
Writing to this will cause the kernel to drop clean caches, dentries and inodes from memory, causing that memory to become free.
To free pagecache: echo 1 > /proc/sys/vm/drop_caches To free dentries and inodes: echo 2 > /proc/sys/vm/drop_caches To free pagecache, dentries and inodes: echo 3 > /proc/sys/vm/drop_caches
As this is a non-destructive operation and dirty objects are not freeable, the user should run `sync' first.
<snap>
wird hier nur der Cache gelöscht. Dies sollte aus meiner Sicht unnötig sein, da der Cache (auch der belegte) jederzeit frei gegeben wird.
Kernelbug? Oder blöde race condition?
H.
Command, n.: Statement presented by a human and accepted by a computer in such a manner as to make the human feel as if he is in control. http://www.hilmar-preusse.de.vu/ _______________________________________________ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
On 20.01.14 Grimnin Fridyson (fridy_lugdd@yahoo.de) wrote:
Moin,
vielleicht hat ein schlauer "Entwickler" eine Prüfroutine drin die checkt ob genügent RAM frei ist.
Leider war ich etwas ungenau. Die Applikation fährt auch wieder hoch, nur fängt sie dann an zu viel RAM zu allokieren, wodurch sie selber unbenutzbar wird. Der RAM sollte eigentlich im Cache sein (also frei sein). Leider scheint die Cache-Freigabe aber nicht zu funktionieren und muß vor dem Neustart erzwungen werden.
Vielleicht ist es ein Kernelkäfer möglicherweise aber auch ein Hardwarefehler der deshalb auftritt das wenn Cache nicht gelehrt wird, ein kaputter Bereich genommen wird.
Dann würde ich aber erwarten, daß auch Probleme auftreten, wenn die Applikation läuft und zufällig auf einen RAM-Riegel tritt, der kaputt ist.
H.
Hallo Hillmar,
On 19 Jan 2014, at 23:17, Hilmar Preusse hille42@web.de wrote:
Moin,
eine Kunde von uns hat eine Applikation die ganz schön viel RAM braucht (so 80GB) auf RH 6.x. Wenn er diese stoppt kann sie anschließend nicht wieder korrekt gestartet werden. Er hat heraus gefunden, daß man den Cache vom OS vorher explizit leeren kann und dann fährt die Applikation wieder hoch.
Darf man erfahren, was das für eine Applikation ist? Verwendet die Applikation mlock(2)? Braucht die Applikation die besagten 80GB direkt nach dem Start oder allokiert sie diese nur?
As this is a non-destructive operation and dirty objects are not freeable, the user should run `sync' first.
<snap>
wird hier nur der Cache gelöscht. Dies sollte aus meiner Sicht unnötig sein, da der Cache (auch der belegte) jederzeit frei gegeben wird.
Naja, teilweise halt, dirty-pages z.B. nicht (steht ja auch in der Doku). Ich bin mir sicher, es gibt auch noch einige SLAB-Caches die nicht sofort reclaimable sind.
Da dies mit sehr hoher Wahrscheinlichkeit ein NUMA-System ist, was sagt den z.B. "numactl -H” vor dem Start und auf was steht der Kernel-Parameter vm.zone_reclaim_mode? Auf was ist vm.overcommit_memory gestellt?
MfG Martin
On 20.01.14 Mailingliste (ml@megamaddin.org) wrote:
Hallo,
Darf man erfahren, was das für eine Applikation ist? Verwendet die Applikation mlock(2)?
Eine Vertica DB. Kann ich nicht sagen.
Braucht die Applikation die besagten 80GB direkt nach dem Start oder allokiert sie diese nur?
Pheew. Kann man das von außen erkennen, ob eine Applikation den RAM nur allokiert hat und diesen aber nicht nutzt.
wird hier nur der Cache gelöscht. Dies sollte aus meiner Sicht unnötig sein, da der Cache (auch der belegte) jederzeit frei gegeben wird.
Naja, teilweise halt, dirty-pages z.B. nicht (steht ja auch in der Doku).
Nun, auch das echo-Kommando gibt ja nur nicht-dirty pages frei. Insofern sollte das Problem darstellen.
Ich bin mir sicher, es gibt auch noch einige SLAB-Caches die nicht sofort reclaimable sind.
Ich warte jetzt erstmal auf den Input von unten, dann schauen wir weiter.
Da dies mit sehr hoher Wahrscheinlichkeit ein NUMA-System ist, was sagt den z.B. "numactl -H” vor dem Start und auf was steht der Kernel-Parameter vm.zone_reclaim_mode? Auf was ist vm.overcommit_memory gestellt?
Muß ich alles erfragen, ich habe keinen Zugriff aufs System.
H.
Hi Hilmar,
On 21.01.2014, at 10:20, Hilmar Preusse hille42@web.de wrote:
Braucht die Applikation die besagten 80GB direkt nach dem Start oder allokiert sie diese nur?
Pheew. Kann man das von außen erkennen, ob eine Applikation den RAM nur allokiert hat und diesen aber nicht nutzt.
ps -eF oder atop oder top
VSZ vs. RSS VSZ = Größe des virtuelle Adressbereiches des Prozesses (inkl. shared Libs und gemappter Dateien) RSS = resident set size - der im RAM befindliche Anteil des virtuellen Speichers des Prozess (Pi mal Daumen der allokierte Speicher)
Was noch mal relevant wäre, hasst du eine Fehlermeldung der Applikation?
MfG Martin
On 20.01.14 Mailingliste (ml@megamaddin.org) wrote:
Moin,
wird hier nur der Cache gelöscht. Dies sollte aus meiner Sicht unnötig sein, da der Cache (auch der belegte) jederzeit frei gegeben wird.
Naja, teilweise halt, dirty-pages z.B. nicht (steht ja auch in der Doku). Ich bin mir sicher, es gibt auch noch einige SLAB-Caches die nicht sofort reclaimable sind.
Der Kunde hat kein sync ausgeführt, also gabs scheinbar keine dirty pages, sonst hätte es nicht geholfen.
Da dies mit sehr hoher Wahrscheinlichkeit ein NUMA-System ist, was sagt den z.B. "numactl -H” vor dem Start und auf was steht der Kernel-Parameter vm.zone_reclaim_mode? Auf was ist vm.overcommit_memory gestellt?
Ich vermute, Du beziehst Dich auf das hier http://www.poempelfox.de/blog/2010/03/
Ich häng Dir erstmal den Output von zoneinfo an. Eventuell sagt es ja was.
Default:
vm.overcommit_memory = 0 vm.overcommit_ratio = 50 vm.zone_reclaim_interval = 30 vm.zone_reclaim_mode = 0
H.
Hi Hilmar,
On 21.01.2014, at 16:31, Hilmar Preusse hille42@web.de wrote:
Der Kunde hat kein sync ausgeführt, also gabs scheinbar keine dirty pages, sonst hätte es nicht geholfen.
Da dies mit sehr hoher Wahrscheinlichkeit ein NUMA-System ist, was sagt den z.B. "numactl -H” vor dem Start und auf was steht der Kernel-Parameter vm.zone_reclaim_mode? Auf was ist vm.overcommit_memory gestellt?
Ich vermute, Du beziehst Dich auf das hier http://www.poempelfox.de/blog/2010/03/
Nein, Erfahrungswerte ;-)
Ich häng Dir erstmal den Output von zoneinfo an. Eventuell sagt es ja was.
Ist das die Information vor dem Neustart oder während die Applikation läuft? Im System sind 2 NUMA-Nodes mit jeweils 48GB RAM, was sagt nun ein numactl -H vor dem Neustart?
Default:
vm.overcommit_memory = 0 vm.overcommit_ratio = 50
vm.zone_reclaim_interval = 30 vm.zone_reclaim_mode = 0
Du könntest Testweise vm.overcommit_memory = 1 mit vm.zone_reclaim_mode = 1 probieren. Das erstere führt dazu, dass man quasi beliebig viel Speicher allokieren kann (der Wert 0 ist eine heuristische Konfiguration, bei der der Kernel probiert zu "schätzen" ob der freie Speicher für die Allokation reicht). Der zweite Wert führt dazu, dass in der zu allokierenden Zone, auf dem aktuellen NUMA-Node, probiert wird, einfach freizugebender Speicher wieder freizugeben (also z.B. page cache), wenn die Gefahr besteht, dass die Zone "leer" läuft.
Wie schon in der vorherigen Mail geschrieben, interessant wäre noch die Fehlermeldung der Applikation.
MfG Martin
Hi,
On Sunday, Sunday 19 January 2014 at 23:17, Hilmar Preusse wrote:
eine Kunde von uns hat eine Applikation die ganz schön viel RAM braucht (so 80GB) auf RH 6.x. Wenn er diese stoppt kann sie anschließend nicht wieder korrekt gestartet werden. Er hat heraus gefunden, daß man den Cache vom OS vorher explizit leeren kann und dann fährt die Applikation wieder hoch.
Industriekunde? Oder eher akademischer Kunde?
Erstere stricken Programme immer mit der heißen Nadel. Letztere kann man überzeugen sich den Bug richtig anzuschaun.
Kernelbug? Oder blöde race condition?
Kernelbug ist nicht unmöglich, aber unwahrscheinlich.
Ich würde mal eine Nacht lang memtest drüber laufen lassen. Es klingt zwar so als wäre es ein System welches natürlicherweise mit ordentlichem ECC-RAM kommt, aber man weiß nie...
Race Condition halte ich für sehr wahrscheinlich. Gecachte Daten ändern die Laufzeiten gewaltig. Nach meiner Erfahrung sind 95% solcher Effekte simple Race Conditions.
Tipps:
* schau mal ob es offensichtlich ungesicherten parallelen Code gibt
* schau Dir alle Stellen an die (u)sleep machen, um irgendetwas anderem Zeit zu geben
* wenn es nichts offensichtliches gibt: Valgrind.
Konrad
On 21.01.14 Konrad Rosenbaum (konrad@silmor.de) wrote:
On Sunday, Sunday 19 January 2014 at 23:17, Hilmar Preusse wrote:
Moin,
eine Kunde von uns hat eine Applikation die ganz schön viel RAM braucht (so 80GB) auf RH 6.x. Wenn er diese stoppt kann sie anschließend nicht wieder korrekt gestartet werden. Er hat heraus gefunden, daß man den Cache vom OS vorher explizit leeren kann und dann fährt die Applikation wieder hoch.
Industriekunde? Oder eher akademischer Kunde?
Ja, Industriekunde: eine Vertica DB.
Ich würde mal eine Nacht lang memtest drüber laufen lassen. Es klingt zwar so als wäre es ein System welches natürlicherweise mit ordentlichem ECC-RAM kommt, aber man weiß nie...
Auf einem produktiven Server ein memtest laufen lassen? Damit werde ich wohl nicht durchkommen.
Race Condition halte ich für sehr wahrscheinlich. Gecachte Daten ändern die Laufzeiten gewaltig. Nach meiner Erfahrung sind 95% solcher Effekte simple Race Conditions.
Danke für sie Einschätzung.
Tipps:
...setzen zum größten Teil voraus, daß man den Quellcode hat. Haben wir aber nicht. Mal schauen, ob wir mit valgrind weiter kommen.
Hilmar
On Tuesday, Tuesday 21 January 2014 at 10:30, Hilmar Preusse wrote:
Tipps:
...setzen zum größten Teil voraus, daß man den Quellcode hat. Haben wir aber nicht. Mal schauen, ob wir mit valgrind weiter kommen.
Hmm, valgrind wird Dir in diesem Fall leider auch nicht viel helfen. Du wirst Hinweise auf Fehlverhalten bekommen, aber ohne Debug-Symbole und Quellen ist es schwer echte Fehler von False-Positives zu unterscheiden.
Vorsicht: app in valgrind verbraucht wesentlich mehr Speicher als app alleine und das Laufzeitverhalten ändert sich so stark dass Du den Fehler nicht exakt wiederfinden wirst! Die Race Condition, die das Problem verursacht sollte aber trotzdem in den Tonnen von Ausgaben auftauchen.
Bei sowas muss generell derjenige an die Analyse ran, der den Code verbrochen hat. Oder zumindest jemand mit Zugriff auf Quellen.
Der nächste Schritt wäre also den HP-Support ranzuholen.
Konrad
On 21.01.14 Konrad Rosenbaum (konrad@silmor.de) wrote:
Moin,
Bei sowas muss generell derjenige an die Analyse ran, der den Code verbrochen hat. Oder zumindest jemand mit Zugriff auf Quellen.
Der nächste Schritt wäre also den HP-Support ranzuholen.
Es handelt sich um eine Embedded data base, die ein Produkt unseres Vendors mit sich herum schleift. Ja, der Vendor ist informiert, mal sehn ob von dort etwas Brauchbares kommt.
Wegen des beschriebenen Verhaltens hatte ich aber zunächst auf Kernelbug oder Race-Condition getippt, sie sich nicht durch Änderung des Codes der Anwendung beheben läßt.
H.
Hi,
On Monday, Monday 27 January 2014 at 14:34, Hilmar Preusse wrote:
Wegen des beschriebenen Verhaltens hatte ich aber zunächst auf Kernelbug oder Race-Condition getippt, sie sich nicht durch Änderung des Codes der Anwendung beheben läßt.
Nach meiner Erfahrung trifft meistens eine ganz einfache Fehlerhierarchie zu:
1) Anwender hat einen Fehler bei der Bedienung gemacht - das ist nicht unbedingt Schuld des Anwenders, sondern ist oft einfach schlechtes Design (ich schließe meine eigenen Programme da durchaus ein)
2) Admin hat Konfigurationsfehler bei Einrichtung des Programms an sich gemacht - Doku und Foren checken hilft meistens schon (kurz: Du hast Dich korrekt verhalten)
3) Admin hat Konfigurationsfehler bei Einrichtung eines anderen Programms gemacht mit dem das Programm interagieren muss (z.B. DB-Server, Web-Server)
4) Anwendungsprogrammierer hat einen Fehler gemacht - normalerweise ist die Anwendung der Teil, der unter dem größten Zeitdruck programmiert wurde und auch der Teil mit den wenigsten Betatestern (ähh, ich meine: Usern) - ein Fehler pro hundert Code-Zeilen ist normal, einer pro tausend ist Spitzenklasse; es ist auch normal Fehler Jahre nach der Programmierung einer Funktion zu finden, weil sich die "Umwelt" eines Programms ständig ändert und Fehler oft sehr versteckt sind
5) Der Fehler liegt in einer Anwendung mit der das Programm interagiert. Je größer die User-Basis des Programms umso wahrscheinlicher ist es schon gut getestet.
6) Kompatibilätsprobleme mit dem darunterliegenden System: veraltete oder fehlerhafte Bibliotheken, Verhalten welches auf System A angepasst ist die App läuft aber auf System B, etc.pp.
7) Irgendein zentraler Server-Prozess hat einen Fehler - das ist bereits sehr selten, da sowas wie Datenbanken und Webserver sehr viele Tester/User haben.
8) Das Betriebssystem oder Compiler hat einen Fehler: -> unter Linux ist das so selten dass ich mich nicht einmal an den letzten Fehler erinnern kann -> unter Windows nennt man das "Rückwärtskompatibilität" und die Workarounds sind relativ gut dokumentiert oder es gibt zumindest tausende Foreneinträge dazu - siehe 6 -> in meiner ganzen Karriere ist mir exakt ein Compilerfehler untergekommen, den ich durch Upgrade auf eine neue Version gelöst habe (der zweite war eine Fehldiagnose meinerseits)
Ein paar geschätzte Zahlen dazu: ca. 90% aller Probleme, die ich mit industriell eingesetzten Applikationen hatte fielen in die ersten 3 Kategorien. Ca. 6% fielen in Klasse 4, weitere 3% in Klasse 5 (ich arbeite mit relativ stark vernetzten Systemen). Der überwÄltigende Teil des letzten Prozents waren Kompatibilitätsprobleme mit Multi-Plattform-Apps. Ich kann mich im Moment nicht erinnern wann genau ich das letzte mal über ein Problem aus Kategorie 7 oder 8 gestolpert bin.
Egal wie es auf den ersten Blick aussieht, meine Erfahrung zeigt dass man eine Diagnose immer mit der Vermutung User-Fehler beginnen sollte, dann Programmierfehler und erst nach Ausschluss aller Möglichkeiten kommt Systemfehler in Betracht.
Konrad
On 28.01.14 Konrad Rosenbaum (konrad@silmor.de) wrote:
On Monday, Monday 27 January 2014 at 14:34, Hilmar Preusse wrote:
Moin,
Wegen des beschriebenen Verhaltens hatte ich aber zunächst auf Kernelbug oder Race-Condition getippt, sie sich nicht durch Änderung des Codes der Anwendung beheben läßt.
Nach meiner Erfahrung trifft meistens eine ganz einfache Fehlerhierarchie zu:
Vielen Dank für Deine Hinweise. Vielen Dank auch an alle Thread-Beiträge!
Aufgrund einer Familienerweiterung bin ich derzeit nicht auf Arbeit und kann daher an dem Problem nicht weiterarbeiten. Ich sage darum "EOT", falls ich nochmal Eure Hilfe brauche mache ich einen Neuen auf!
Hilmar
lug-dd@mailman.schlittermann.de
-
Grimnin Fridyson -
Hilmar Preusse -
Konrad Rosenbaum -
Maddin -
Mailingliste