Hallo allerseits, ich hab' hier bei einem neu aufgesetzten Server unter 9.2 ein mächtiges Problem. Das Gerät ist ein Allround-Server: web, mail, ftp, cups, samba, etc. pp. Normalerweise laufen darauf so ca. 120 Prozesse aufwärts, und das mit einer zugegebenermassen schwachen Hardware: Athlon 500, 256 MB. 2 GB Swap vorhanden. Nun ist es so, dass ich schon ohne laufenden apache eine load von 2,2 typisch habe. Reaktionszeiten bei imap-Zugriffen sind träge, auf der Konsole ist alles entsprechend langsam. Zunächst war's so das der oom-killer auch regelmäßig Prozesse wie dhcpd, ldap oder named gekillt hat. Das ist nicht gut, nach etwas rumsuchen habe ich also vm.overcommit_memory auf 2 gesetzt, damit bleiben die Prozesse wenigstens amlaufen. Nur hab' ich mit apache und einemlaufenden Backup dann eine load von 11 oder 12 odersteigend, und entsprechend timeouts bei DNS- oder dhcp-Anfragen. Also auch unbrauchbar. Nach einem Neustrat nach Kernelaktualisierung hatte ich dann mal gute Antwortzeiten, und load unter 0.2. So sollte es sein, dachte ich und war zufrieden. Blieb aber nicht dabei, aus für mich nicht nachvollziehbaren Gründen war nach einiger Betriebszeit alles wieder beim alten und schlechten. Weiss jemand Rat? Ach so, der Vorgänger ist ein Pentium 200, mit älerer, anderer Software, aber den gleichen Diensten. Der reagiert flott auf der Konsole, load bei 0,2, nur bei imap-Zugriffen und als Webserver wurde er zu langsam. Danke für Hinweise schonmal, Arno -- IT-Service Lehmann al@its-lehmann.de Arno Lehmann http://www.its-lehmann.de
Moin und frohe Ostern. Bisher hat sich ja niemand für das Problem interessiert. Also fasse ich mal zusammen was ich bisher rausbekommen habe. (TOFU bleibt, falls doch jemand nachlesen will...) Situation: Athlon 500, 512 MB, 2GB Swap, jede Menge Software. Nach Start ca. 300MB RAM belegt, load liegt typischerweise knapp über 0, und deutlich unter 0,1. Es laufen jede Menge Prozesse. Nach etwa 24-36 Stunden fängt der oom-killer im Kernel an Prozesse abzuschiessen bis der Server nicht mehr ansprechbar ist - irgendwann hat's ldap, bind, named etc. weggeputzt. Das beobachte ich jetzt schon eine ganze Weile. Ich habe elf:~ # cat /proc/sys/vm/overcommit_memory 2 eingestellt, das hat das Problem verbessert, aber nicht behoben. Im Moment monitore ich per rrd den systemload und speichere mir jede Minute den Output von free und ps -eopid,user,rss,sz,cmd . Was ich bisher sehe: Es wird Speicher verbraten. Und zwar nicht zu knapp: Sun Mar 27 20:40:28 CEST 2005 total used free shared buffers cached Mem: 515636 377780 137856 0 77616 112284 -/+ buffers/cache: 187880 327756 Swap: 2120540 0 2120540 Sun Mar 27 21:35:32 CEST 2005 total used free shared buffers cached Mem: 515636 510260 5376 0 78924 112000 -/+ buffers/cache: 319336 196300 Swap: 2120540 0 2120540 In 55 Minuten vo 190M auf 320M... und zwar ohne dass ich ein Programm festmachen könnte das den Speicherverbrauch erklärt. Der letzte Durchgang des out-of-memory killers danach war dann der Reboot fällig...) brachte folgendes Log:
Mar 27 18:01:25 elf kernel: oom-killer: gfp_mask=0x1d2 Mar 27 18:01:25 elf kernel: DMA per-cpu: Mar 27 18:01:25 elf kernel: cpu 0 hot: low 2, high 6, batch 1 Mar 27 18:01:25 elf kernel: cpu 0 cold: low 0, high 2, batch 1 Mar 27 18:01:25 elf kernel: Normal per-cpu: Mar 27 18:01:25 elf kernel: cpu 0 hot: low 32, high 96, batch 16 Mar 27 18:01:25 elf kernel: cpu 0 cold: low 0, high 32, batch 16 Mar 27 18:01:25 elf kernel: HighMem per-cpu: empty Mar 27 18:01:25 elf kernel: Mar 27 18:01:25 elf kernel: Free pages: 3224kB (0kB HighMem) Mar 27 18:01:25 elf kernel: Active:64569 inactive:57774 dirty:0 writeback:5 unstable:0 free:806 slab:3824 mapped:1358 pagetables:283 Mar 27 18:01:25 elf kernel: DMA free:2000kB min:20kB low:40kB high:60kB active:5460kB inactive:4820kB present:16384kB Mar 27 18:01:25 elf kernel: lowmem_reserve[]: 0 495 495 Mar 27 18:01:25 elf kernel: Normal free:1224kB min:700kB low:1400kB high:2100kB active:252816kB inactive:226276kB present:507840kB Mar 27 18:01:25 elf kernel: lowmem_reserve[]: 0 0 0 Mar 27 18:01:25 elf kernel: HighMem free:0kB min:128kB low:256kB high:384kB active:0kB inactive:0kB present:0kB Mar 27 18:01:25 elf kernel: lowmem_reserve[]: 0 0 0 Mar 27 18:01:25 elf kernel: DMA: 0*4kB 0*8kB 1*16kB 0*32kB 1*64kB 1*128kB 1*256kB 1*512kB 1*1024kB 0*2048kB 0*4096kB = 2000kB Mar 27 18:01:25 elf kernel: Normal: 136*4kB 9*8kB 2*16kB 2*32kB 0*64kB 0*128kB 0*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 1224kB Mar 27 18:01:25 elf kernel: HighMem: empty Mar 27 18:01:25 elf kernel: Swap cache: add 2103349, delete 2102994, find 570985/1079762, race 74+685 Mar 27 18:01:25 elf kernel: Free swap = 2094636kB Mar 27 18:01:25 elf kernel: Total swap = 2120540kB Mar 27 18:01:25 elf kernel: Out of Memory: Killed process 27813 (httpd2-prefork).
Daraus kann ich nur sehen dass zwar jede Menge Swapspace da ist, aber wegen Mangels irgendwelchen Speichers gekillt wurde. Wer kann mir hir einen Tip geben? Arno Arno Lehmann wrote:
Hallo allerseits,
ich hab' hier bei einem neu aufgesetzten Server unter 9.2 ein mächtiges Problem.
Das Gerät ist ein Allround-Server: web, mail, ftp, cups, samba, etc. pp.. Normalerweise laufen darauf so ca. 120 Prozesse aufwärts, und das mit einer zugegebenermassen schwachen Hardware: Athlon 500, 256 MB. 2 GB Swap vorhanden.
Nun ist es so, dass ich schon ohne laufenden apache eine load von 2,2 typisch habe. Reaktionszeiten bei imap-Zugriffen sind träge, auf der Konsole ist alles entsprechend langsam.
Zunächst war's so das der oom-killer auch regelmäßig Prozesse wie dhcpd, ldap oder named gekillt hat. Das ist nicht gut, nach etwas rumsuchen habe ich also vm.overcommit_memory auf 2 gesetzt, damit bleiben die Prozesse wenigstens amlaufen. Nur hab' ich mit apache und einemlaufenden Backup dann eine load von 11 oder 12 odersteigend, und entsprechend timeouts bei DNS- oder dhcp-Anfragen. Also auch unbrauchbar.
Nach einem Neustrat nach Kernelaktualisierung hatte ich dann mal gute Antwortzeiten, und load unter 0.2.
So sollte es sein, dachte ich und war zufrieden.
Blieb aber nicht dabei, aus für mich nicht nachvollziehbaren Gründen war nach einiger Betriebszeit alles wieder beim alten und schlechten.
Weiss jemand Rat?
Ach so, der Vorgänger ist ein Pentium 200, mit älerer, anderer Software, aber den gleichen Diensten. Der reagiert flott auf der Konsole, load bei 0,2, nur bei imap-Zugriffen und als Webserver wurde er zu langsam.
Danke für Hinweise schonmal,
Arno
-- IT-Service Lehmann al@its-lehmann.de Arno Lehmann http://www.its-lehmann.de
Arno Lehmann wrote:
Situation: Athlon 500, 512 MB, 2GB Swap, jede Menge Software. Nach Start ca. 300MB RAM belegt, load liegt typischerweise knapp über 0, und deutlich unter 0,1. Es laufen jede Menge Prozesse.
Nach etwa 24-36 Stunden fängt der oom-killer im Kernel an Prozesse abzuschiessen bis der Server nicht mehr ansprechbar ist - irgendwann hat's ldap, bind, named etc. weggeputzt.
Das laesst darauf schliessen, dass der Speicher ausgeht. Der Cache im Speicher wuerde z.B. automatisch verkleinert werden.
[...] Im Moment monitore ich per rrd den systemload und speichere mir jede Minute den Output von free und ps -eopid,user,rss,sz,cmd .
Was ich bisher sehe: Es wird Speicher verbraten. Und zwar nicht zu knapp:
Sun Mar 27 20:40:28 CEST 2005 total used free shared buffers cached Mem: 515636 377780 137856 0 77616 112284 -/+ buffers/cache: 187880 327756 Swap: 2120540 0 2120540
Sun Mar 27 21:35:32 CEST 2005 total used free shared buffers cached Mem: 515636 510260 5376 0 78924 112000 -/+ buffers/cache: 319336 196300 Swap: 2120540 0 2120540
In 55 Minuten vo 190M auf 320M... und zwar ohne dass ich ein Programm festmachen könnte das den Speicherverbrauch erklärt.
Buffer und Cache sind in etwa gleich geblieben, genutzter Speicher stieg von ca. 380 MB auf 510 MB (=130 MB), entsprechend ging der freie Speicher etwa um die gleiche Menge zurueck. Noch ist alles i.O., d.h. es ist genuegend RAM vorhanden, um Speicher allokieren zu koennen, aber wenn es so weiter geht, ist das natuerlich nicht so gut... Was fuer einen Kernel nutzt Du? Und wie ist Dein Swap-Bereich konfiguriert? Hast Du Speicher mit memtest mal getestet, nur um ein physikalisches Problem auszuschliesen?
Der letzte Durchgang des out-of-memory killers danach war dann der Reboot fällig...) brachte folgendes Log:
Der Kernel sollte nur anfangen, Prozesse zu killen, wenn das der letzte Ausweg ist (oder es ist ein buggy Kernel). Es koennte sein, dass ein Programm ein memory leak hat, d.h. je laenger es laeuft, desto mehr Speicher braucht es. Das muesste sich aber dann auf alle Faelle feststellen lassen. Was ergab Dein Speicher-Monitoring? Cheers, Th.
Moin. Thomas Hertweck wrote:
Arno Lehmann wrote:
Situation: Athlon 500, 512 MB, 2GB Swap, jede Menge Software. Nach Start ca. 300MB RAM belegt, load liegt typischerweise knapp über 0, und deutlich unter 0,1. Es laufen jede Menge Prozesse.
Nach etwa 24-36 Stunden fängt der oom-killer im Kernel an Prozesse abzuschiessen bis der Server nicht mehr ansprechbar ist - irgendwann hat's ldap, bind, named etc. weggeputzt.
Das laesst darauf schliessen, dass der Speicher ausgeht. Der Cache im Speicher wuerde z.B. automatisch verkleinert werden.
Eben da scheint das Problem zu liegen.
[...] Im Moment monitore ich per rrd den systemload und speichere mir jede Minute den Output von free und ps -eopid,user,rss,sz,cmd .
Was ich bisher sehe: Es wird Speicher verbraten. Und zwar nicht zu knapp: ... Buffer und Cache sind in etwa gleich geblieben, genutzter Speicher stieg von ca. 380 MB auf 510 MB (=130 MB), entsprechend ging der freie Speicher etwa um die gleiche Menge zurueck. Noch ist alles i.O., d.h. es ist genuegend RAM vorhanden, um Speicher allokieren zu koennen, aber wenn es so weiter geht, ist das natuerlich nicht so gut... Was fuer einen Kernel nutzt Du? Und wie ist Dein Swap-Bereich konfiguriert? Hast Du Speicher mit memtest mal getestet, nur um ein physikalisches Problem auszuschliesen?
Ja, das war auch nur ein Beispiel, zu einer Zeit aufgenommen, da das noch ging ;-) Kernle 2.6.8-24.13-default per YOU eingespielt, neu gebootet. Memtest lief einige Durchgänge nachdem ich den Speicher vergrößert hatte und fand keine Fehler. 2 GB Swap vorhanden.
Der letzte Durchgang des out-of-memory killers danach war dann der Reboot fällig...) brachte folgendes Log:
Der Kernel sollte nur anfangen, Prozesse zu killen, wenn das der letzte Ausweg ist (oder es ist ein buggy Kernel). Es koennte sein, dass ein Programm ein memory leak hat, d.h. je laenger es laeuft, desto mehr Speicher braucht es. Das muesste sich aber dann auf alle Faelle feststellen lassen. Was ergab Dein Speicher-Monitoring?
Ich habe ja die Hoffnung das solche offensichtlichen Bugs in einem original-SuSE-Kernel nicht enthalten sind. Im Moment, so wie's aussieht, habe ich das Problem etwas eingekreist: Wenn nagios (www.nagios.org, glaub' ich) läuft -> Problem. Wenn's nicht läuft: Kein Problem. Was die Speichernutzung angeht tappe ich immer noch im Dunkel: free sagt: -/+ buffers/cache: 410072 Summe der RSS der Prozesse zu dem Zeitpunkt: 109376 Nun bin ich mir nicht hundertprozentig sicher dass sum(RSS)=used memory - buffers - cache gilt, aber die Differenz ist doch ziemlich groß. Im Verdacht habe ich inzwischen Netzwerkverbindungen und Sockets die von Prozessen offengelassen werden. Denn: Während nagios läuft und regelmäßig monitoring-Prozesse startet gibt mir netstat -a|wc -l mehr als 600 aus, ohne nagios ~230 Aber brauchen 370 offene connections hunderte MB Speicher? Ich glaub' nicht... Gibt es noch andere, detailliertere Möglichkeiten als free und ps -eopid,user,rss,sz,cmd die tatsächliche Speichernutzung von Prozessen zu ermitteln? Arno
Cheers, Th.
-- IT-Service Lehmann al@its-lehmann.de Arno Lehmann http://www.its-lehmann.de
Arno, eine Email an die Liste genuegt, ich brauche die Mail nicht nochmal als Privat-Kopie... Arno Lehmann wrote:
[...] Ich habe ja die Hoffnung das solche offensichtlichen Bugs in einem original-SuSE-Kernel nicht enthalten sind.
Diese Naivitaet hatte ich auch mal :-) Dann erlebte ich den SuSE-Kernel der 8.0 Distro...
Im Moment, so wie's aussieht, habe ich das Problem etwas eingekreist: Wenn nagios (www.nagios.org, glaub' ich) läuft -> Problem. Wenn's nicht läuft: Kein Problem.
Wie vermutet, eher eine Problem der Anwendungssoftware und nicht des Kernels.
[Problem mit nagios]
Dazu kann ich nichts sagen, kenne die Software nicht und weiss nicht, wie sie im Detail funktioniert. Evtl. liegt in bestimmten Situationen ein memory leak vor.
Gibt es noch andere, detailliertere Möglichkeiten als free und ps -eopid,user,rss,sz,cmd die tatsächliche Speichernutzung von Prozessen zu ermitteln?
Evtl. hilft memusage oder memprof. Ein kleines nettes Tool ist auch gmemusage - leider fehlen unter Linux da jede Menge Features im Vergleich zur SGI Version, die ich kenne... Cheers, Th.
participants (2)
-
Arno Lehmann -
Thomas Hertweck