SuSe 9.0 Kernel Fehler bzw. RAM

[gabberbert]

Hallo Root Gemeinde,
vor etwa 5 Stunden hat sich mein SuSe Rootie verabschiedet. Habe es erst bemerkt als der Apache nicht mehr lief. Ssh Login auch nicht mehr möglich. Sowie über die Remote Console vom Provider.

Habe dann ein Hardreset machen müssen. Danach habe ich mich wieder eingeloggt und mit tail -f messesage geschaut was passiert.

Nach etwa 20 minuten bekomme ich folgende Einträge als Ausgabe und dann geht nichts mehr.

Code: Select all

May 18 19:46:38 h5252 kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
May 18 19:46:38 h5252 kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
May 18 19:46:38 h5252 kernel: VM: killing process httpd2-prefork
May 18 19:46:39 h5252 /USR/SBIN/CRON[2800]: (root) CMD (/root/srvreport/bin/srvreport.pl)
May 18 19:48:31 h5252 syslogd: /var/log/mail.info: Cannot allocate memory
May 18 19:48:19 h5252 kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
May 18 19:48:19 h5252 kernel: VM: killing process sh
May 18 19:48:20 h5252 kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
May 18 19:48:23 h5252 last message repeated 4 times
May 18 19:48:23 h5252 kernel: VM: killing process httpd2-prefork
May 18 19:48:24 h5252 kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
May 18 19:48:33 h5252 kernel: VM: killing process sh
May 18 19:48:36 h5252 kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
May 18 19:48:36 h5252 last message repeated 2 times
May 18 19:48:36 h5252 kernel: __alloc_pages: 0-order allocation failed (gfp=0x1f0/0)
May 18 19:48:36 h5252 kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
May 18 19:48:36 h5252 last message repeated 3 times
May 18 19:48:36 h5252 kernel: VM: killing process httpd2-prefork
May 18 19:48:36 h5252 kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
May 18 19:48:36 h5252 last message repeated 3 times
May 18 19:48:36 h5252 kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d0/0)
May 18 19:48:36 h5252 kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
May 18 19:48:36 h5252 kernel: VM: killing process httpd2-prefork

Ein Ping kann ich in diesem Zustand noch an ihn schicken. Aber drauf connecten unmöglich.

Was kann das sein. Für mich sieht das nach einem Hardwaredefekt aus.
Würde aber gern noch die Meinung Anderer haben.

Edit: Meine natürlich dass der RAM defekt sein wird. Nicht der Kernel.

Bitte um Hilfe.

mfG
Konstantin

[golloza]

OOM-Killer, d.h. kein freier Speicher mehr verfügbar.

Swap aktiviert?

[gabberbert]

Code: Select all

top - 06:54:45 up 10:56,  1 user,  load average: 0.00, 0.03, 0.06
Tasks:  66 total,   1 running,  64 sleeping,   0 stopped,   1 zombie
Cpu(s):   0.0% user,   0.3% system,   0.0% nice,  99.7% idle
Mem:    514388k total,   483544k used,    30844k free,    61788k buffers
Swap:   514072k total,        0k used,   514072k free,   350080k cached

Swap war und ist die ganze Zeit aktiviert.

Free zeigt mir auch den Swap an.

Code: Select all

free
             total       used       free     shared    buffers     cached
Mem:        514388     484336      30052          0      61820     350100
-/+ buffers/cache:      72416     441972
Swap:       514072          0     514072

Das System lief jetzt die ganze nacht. Nur mit paar kleinen Prozessen (BNC und Teamspeak). Mach ich aber den Apache an wird der die Swap Partition genutzt und schwups beendet er einfach alles was stört.

Was kann ich dagegen machen? Trat von einer Minute auf die Andere auf :?

Nachtrag: Im Yast sehe ich die Partition Swap. Allerdings mit df in der Konsole nicht, ist das korrekt?

Code: Select all

   Gerät    │    Größe   │ F │Typ                      │ Mountp. │Anfang│ Ende│Belegt │  │
│ │/dev/hda │     57.2 GB│   │ExcelStor Technology J360│         │     0│ 7475│       │  │
│ │/dev/hda1│     54.9 MB│   │Linux native             │/boot    │     0│   6 │       │  │
│ │/dev/hda2│    502.0 MB│   │Linux native             │swap     │     7│  70 │       │  │
│ │/dev/hda3│     56.7 GB│   │Linux native             │/        │    71│7475 │       │  │

df:

Code: Select all

Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/hda3             58546976  20469044  37483128  36% /
/dev/hda1                54416      9575     44280  18% /boot
tmpfs                   257192         0    257192   0% /dev/shm

Und hier ist noch ein Bild vom Start. Meldet dort zumindest keine Fehler zwecks RAM.

http://www.world-of-alien.de/temp/boot.gif
Hmm ohne Apache gehts schlecht :x

[golloza]

Ich würde zuerst mal den Kernel updaten, 2.4.25 ist uralt und seitdem wurden einige Sicherheitslücken gefixt.

df zeigt nur die gemounteten Dateisysteme an, es ist also normal, dass Swap da nicht auftaucht
free oder swapon -s zeigen Swap an.

Der Apache scheint extrem viel Speicher zu reservieren.
Was laufen da für Scripte?
PHPs memory_limit hilft dir vielleicht weiter.

[gabberbert]

Ok, swapon meint die Swap ist da. Leider war der RAM noch nicht voll, so das die Swap Partition genutzt werden musste. Aber ich denke heute Abend wir das noch passieren.

Es laufen ziemlich viele Foren welche auch sehr gut besuchst sind.
Der Apache verarbeitet rund 300.000 Hits am tag.

memory_limit steht stand auf 8MB

Hier is noch ein Screen von der Auslastung.
http://www.world-of-alien.de/temp/top.gif
Eigentlich müsste doch ein 2.4GHZ CPU das packen?!

[golloza]

Die CPU ist auch nicht das Problem, sondern der verfügbare Speicher (Load ist ja auch ok).

memory_limit von 8MB ist in Ordnung, denke ich.
Als nächstes würde ich mir mal die Einstellungen vom Prefork MPM vornehmen (StartServers, MaxSpareServers, MaxClients).
Und wie gesagt, ein Update auf 2.4.30 ist absolut angebracht, vielleicht hat ja auch der OOM Killer in alten Versionen einen Bug.

[alexander newald]

Einfach mal folgendes probieren:

Alle Prozesse beenden, die nicht wirklich nötig sind. Evtl. nur per Serieller Konsole einloggen und alles andere beenden.

Möglichst alle Partitionen ro mounten

mount -o remount,ro /dev/irgendwas

dann:

perl -e "print 'x'x100000"

Sowie er etwas ausgibt, kann die Ausgabe mit STRG-C abgebrochen werden.

Die Zahl 100000 immer weiter erhöhen (am Anfang zB. immer mal 100 order mal 10) bis die Meldung kommt, dass nicht genug Speicher zur Verfügung steht. Dann kleine Schritte nehmen, biss man sich an eine möglichst grosse Zahl herangetastet hat.

Das print von Perl braucht auf diese Art richtig viel Speicher und man kann so einfach und schnell den Speicher testen.

[mrturkey]

Ich kann dir eventuell meine Erfahren mit u.a dem selbigen Problem.

Mein Server hatte sich desöfteren verabschiedet und ich musste den Server immer über das Kundencenter manuell rebooten, weil einfach nichts mehr funktioniert hatte.

Hier mal ein Auszug aus meiner Log :

Code: Select all

ay 13 01:55:18 h101712 kernel: kernel BUG at page_alloc.c:142!
May 13 01:55:18 h101712 kernel: invalid operand: 0000
May 13 01:55:18 h101712 kernel: CPU:    1
May 13 01:55:18 h101712 kernel: EIP:    0010:[__free_pages_ok+92/848]    Not tainted
May 13 01:55:18 h101712 kernel: EIP:    0010:[<c013ce5c>]    Not tainted
May 13 01:55:18 h101712 kernel: EFLAGS: 00010282
May 13 01:55:18 h101712 kernel: eax: 00000000   ebx: c27e2c80   ecx: c038a334   edx: c038a0a0
May 13 01:55:18 h101712 kernel: esi: 00000000   edi: 00000000   ebp: f684f320   esp: eba2be14
May 13 01:55:18 h101712 kernel: ds: 0018   es: 0018   ss: 0018
May 13 01:55:18 h101712 kernel: Process bash (pid: 18459, stackpage=eba2b000)
May 13 01:55:18 h101712 kernel: Stack: 00000000 c018050b f5af8660 f5af8660 0090800b 00001000 f7ba4c94 f7ba4c00
May 13 01:55:18 h101712 kernel:        f5af8660 00000019 0000005d 0006e000 ebe642d8 c012e245 c27e2c80 f0d75440
May 13 01:55:18 h101712 kernel:        eba2bea0 f55cc780 0000005d 0006e000 08448000 0000005d 080b6000 ebf35084
May 13 01:55:18 h101712 kernel: Call Trace:    [ext3_do_update_inode+411/1056] [zap_page_range+501/960] [exit_mmap+224/352] [mmput+109/176] [do_exit+232/1008]
May 13 01:55:18 h101712 kernel: Call Trace:    [<c018050b>] [<c012e245>] [<c01317e0>] [<c011b98d>] [<c01215e8>]
May 13 01:55:18 h101712 kernel:   [collect_signal+169/240] [sig_exit+213/224] [dequeue_signal+100/208] [do_signal+486/720] [sys_rt_sigaction+173/288] [sys_rt$
May 13 01:55:18 h101712 kernel:   [<c0128039>] [<c0127ea5>] [<c01280e4>] [<c01071c6>] [<c0129d3d>] [<c0129d3d>]
May 13 01:55:18 h101712 kernel:   [sys_sigreturn+243/320] [signal_return+20/24]
May 13 01:55:18 h101712 kernel:   [<c01066c3>] [<c010743c>]

Meiner Meinung war es ein defekter Rambaustein, jedoch hat ein 8 stündiger Memtest auch nichts ergeben. Einer der Techniker meinte auch es wäre ein Softwareproblem.

Nun ich bin gestern von 9.0 auf Suse9.2 umgestiegen und muss sagen das es bis jetzt keinerlei Probleme aufgetaucht sind.

Wenn alles nichts nützt kannst ja auch mal probieren.


gr33tz