Re: echo 3 > /proc/sys/vm/drop_caches
Hi Hilmar, > On 21.01.2014, at 16:31, Hilmar Preusse 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 ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: echo 3 > /proc/sys/vm/drop_caches
Hi Hilmar, > On 21.01.2014, at 10:20, Hilmar Preusse 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 ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: echo 3 > /proc/sys/vm/drop_caches
On 20.01.14 Mailingliste (m...@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. -- "Life sucks, but it's better than the alternative." -- Peter da Silva http://www.hilmar-preusse.de.vu/ Output of command cat /proc/zoneinfo: Node 0, zone DMA pages free 2417 min 0 low 0 high 0 active 0 inactive 0 scanned 0 (a: 30 i: 30) spanned 4096 present 2316 nr_anon_pages 0 nr_mapped1 nr_file_pages 0 nr_slab 0 nr_page_table_pages 0 nr_dirty 0 nr_writeback 0 nr_unstable 0 nr_bounce0 numa_hit 0 numa_miss0 numa_foreign 0 numa_interleave 0 numa_local 0 numa_other 0 protection: (0, 2966, 48416, 48416) pagesets all_unreclaimable: 1 prev_priority: 12 start_pfn: 0 Node 0, zoneDMA32 pages free 706102 min 304 low 380 high 456 active 1 inactive 0 scanned 0 (a: 0 i: 10) spanned 1044480 present 759301 nr_anon_pages 1 nr_mapped0 nr_file_pages 0 nr_slab 33 nr_page_table_pages 0 nr_dirty 0 nr_writeback 0 nr_unstable 0 nr_bounce0 numa_hit 192039108 numa_miss4402455 numa_foreign 0 numa_interleave 0 numa_local 191359364 numa_other 5082199 protection: (0, 0, 45450, 45450) pagesets cpu: 0 pcp: 0 count: 150 high: 186 batch: 31 cpu: 0 pcp: 1 count: 4 high: 62 batch: 15 vm stats threshold: 60 cpu: 1 pcp: 0 count: 181 high: 186 batch: 31 cpu: 1 pcp: 1 count: 6 high: 62 batch: 15 vm stats threshold: 60 cpu: 2 pcp: 0 count: 176 high: 186 batch: 31 cpu: 2 pcp: 1 count: 10 high: 62 batch: 15 vm stats threshold: 60 cpu: 3 pcp: 0 count: 175 high: 186 batch: 31 cpu: 3 pcp: 1 count: 54 high: 62 batch: 15 vm stats threshold: 60 cpu: 4 pcp: 0 count: 163 high: 186 batch: 31 cpu: 4 pcp: 1 count: 14 high: 62 batch: 15 vm stats threshold: 60 cpu: 5 pcp: 0 count: 135 high: 186 batch: 31 cpu: 5 pcp: 1 count: 11 high: 62 batch: 15 vm stats threshold: 60 cpu: 12 pcp: 0 count: 129 high: 186 batch: 31 cpu: 12 pcp: 1 count: 14 high: 62 batch: 15 vm stats threshold: 60 cpu: 13 pcp: 0 count: 26 high: 186 batch: 31 cpu: 13 pcp: 1 count: 12 high: 62 batch: 15 vm stats threshold: 60 cpu: 14 pcp: 0 count: 30 high: 186 batch: 31 cpu: 14 pcp: 1 count: 7 high: 62 batch: 15 vm stats threshold: 60 cpu: 15 pcp: 0 count: 7 high: 186 batch: 31 cpu: 15 pcp: 1 count: 56 high: 62 batch: 15 vm stats threshold: 60 cpu: 16 pcp: 0 count: 111 high: 186 batch: 31 cpu: 16 pcp: 1 count: 14 high: 62 batch: 15 vm stats threshold: 60 cpu: 17 pcp: 0 count: 0 high: 186 batch: 31 cpu: 17 pcp: 1 count: 1 high: 62 batch: 15 vm stats threshold: 60 all_unreclaimable: 0 prev_priority: 12 start_pfn: 4096 Node 0, zone Normal pages fr
Re: echo 3 > /proc/sys/vm/drop_caches
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 signature.asc Description: This is a digitally signed message part. ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: echo 3 > /proc/sys/vm/drop_caches
On 21.01.14 Konrad Rosenbaum (kon...@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 -- Usage: fortune -P [-f] -a [xsz] Q: file [rKe9] -v6[+] file1 ... http://www.hilmar-preusse.de.vu/ signature.asc Description: Digital signature ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: echo 3 > /proc/sys/vm/drop_caches
On 20.01.14 Mailingliste (m...@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. -- A woman did what a woman had to, the best way she knew how. To do more was impossible, to do less, unthinkable. -- Dirisha, "The Man Who Never Missed" http://www.hilmar-preusse.de.vu/ signature.asc Description: Digital signature ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: echo 3 > /proc/sys/vm/drop_caches
On 20.01.14 Grimnin Fridyson (fridy_lu...@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. -- Advancement in position. http://www.hilmar-preusse.de.vu/ signature.asc Description: Digital signature ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
