Wie: Absturzsursache bei 1&1 L64 Rootserver feststellen?
Posted: 2006-11-02 00:36
Hallo,
ich habe ein ernsthaftes Problem mit dem Rootserver bei 1&1 (L64). Ich lasse dort eigentlich nichts wildes drauf laufen, als webserver wird er kaum genutzt, es läuft ein kleines wiki, was nur einer handvoll personen bekannt ist, hauptlast ist ein build-server (cruisecontrol/cvs/maven2) und ein application server (Java EE SDK), beides mit entsprechendem speicherbedarf.
Nun ist es so, dass der server eine weile läuft (2-3 Tage), um dann unvermittelt stehen zu bleiben. Bisher ist das genau drei mal passiert. Beim ersten mal hab ich noch was in /var/log/messages finden können, was auf eine ursache hätte schliessen lassen können:
Und auch ein login über die serielle Konsole hat ein paar Fehlermeldungen zu Tage gefördert:
Das Problem war allerdings, dass ich das system nur noch im rescue system booten konnte, das normale wollte absolut nicht mehr mucken. Ein Versuch resultierte auch in keinerlei einträgen in einem file, aus dem man hätte ersehen können, was beim booten klemmt. Ende vom Lied war, dass ich den Server nach etlichen Telefonaten mit dem Support neu Initialisiert habe.
Dann letzten Freitag das gleiche Phänomen, support angerufen, lakonischer kommentar: es konnte kein Problem festgestellt werden, reboot funktionierte.
Dann gestern der nächste Hänger! Diesmal konnte ich den einzig nützlichen Hinweis auf einen Fehler in /var/log/warn finden:
Also wieder was mit dem speicher. Ich hatte aber schon mal einen memtest laufen lassen, allerdings nur im rescue system und dann nur über 500MB, mehr wollte memtest nicht, und auch ohne Resultate.
Preisfrage:
* Gibt es andere Ursachen als einen Hardware defekt? Wenn es an der Hardware liegt, wie kann ich 1&1 das beweisen, dass die mich auf einen anderen Server legen?
* Wie zuverlässig ist der Reboot über die 1&1 webseite, klappt das normalerweise?
* Beim googlen bin ich auf "Xen" gestossen, aber wo sollte das auf einem regulären rootserver zum einsatz kommen?
* Falls ich den server wieder neu initialisieren muss, wie kann ich besser tracen, was passiert, bevor er abstürzt?
Danke für Eure Hilfe, so langsam verzweifle ich.
ich habe ein ernsthaftes Problem mit dem Rootserver bei 1&1 (L64). Ich lasse dort eigentlich nichts wildes drauf laufen, als webserver wird er kaum genutzt, es läuft ein kleines wiki, was nur einer handvoll personen bekannt ist, hauptlast ist ein build-server (cruisecontrol/cvs/maven2) und ein application server (Java EE SDK), beides mit entsprechendem speicherbedarf.
Nun ist es so, dass der server eine weile läuft (2-3 Tage), um dann unvermittelt stehen zu bleiben. Bisher ist das genau drei mal passiert. Beim ersten mal hab ich noch was in /var/log/messages finden können, was auf eine ursache hätte schliessen lassen können:
Code: Select all
Oct 23 23:08:01 s15229400 kernel: <0>Bad page state in process 'javac'
Oct 23 23:08:01 s15229400 kernel: page:ffff810001af7b98 flags:0x0100000000010008 mapping:0000000000000000 mapcount:-1 count:0
Oct 23 23:08:01 s15229400 kernel: Trying to fix it up, but a reboot is needed
Oct 23 23:08:01 s15229400 kernel: Backtrace:
Oct 23 23:08:01 s15229400 kernel:
Oct 23 23:08:01 s15229400 kernel: Call Trace: <ffffffff80151d9f>{bad_page+83} <ffffffff80152684>{free_hot_cold_page+114}
Oct 23 23:08:01 s15229400 kernel: <ffffffff80152db2>{__pagevec_free+28} <ffffffff801559fa>{__pagevec_release_nonlru+124}
Oct 23 23:08:01 s15229400 kernel: <ffffffff80156b7a>{shrink_list+850} <ffffffff8015761b>{shrink_cache+179}
Oct 23 23:08:01 s15229400 kernel: <ffffffff80157dbc>{shrink_zone+215} <ffffffff80157e28>{shrink_caches+86}
Oct 23 23:08:01 s15229400 kernel: <ffffffff80157f25>{try_to_free_pages+234} <ffffffff80152a30>{get_page_from_freelist+111}
Oct 23 23:08:01 s15229400 kernel: <ffffffff80152c14>{__alloc_pages+403} <ffffffff8015c507>{do_anonymous_page+70}
Oct 23 23:08:01 s15229400 kernel: <ffffffff8015cacd>{__handle_mm_fault+396} <ffffffff8011c0fd>{do_page_fault+505}
Oct 23 23:08:01 s15229400 kernel: <ffffffff80473dc6>{thread_return+0} <ffffffff8010b4f1>{error_exit+0}
Code: Select all
Eeek! page_mapcount(page) went negative! (-1)
page->flags = 100000000010038
page->count = 1
page->mapping = ffff81002026de90
----------- [cut here ] --------- [please bite here ] ---------
Kernel BUG at mm/rmap.c:560
BUG: soft lockup detected on CPU#0!
CPU 0:
Modules linked in:
Pid: 230, comm: kswapd0 Tainted: G B 2.6.16.20-060620b #1
RIP: 0010:[<ffffffff80475cf5>] <ffffffff80475cf5>{.text.lock.spinlock+118}
RSP: 0000:ffff81003d97dc40 EFLAGS: 00000286
RAX: ffff81000176de50 RBX: 0000000000000001 RCX: 000000000000003f
RDX: ffff81000000b000 RSI: ffff810000000000 RDI: ffff81000176de60
RBP: 0000000000000004 R08: 00003ffffffff000 R09: 00000000000000fa
R10: ffff810001a35418 R11: ffff81000197ee68 R12: ffffffff801559fa
R13: ffff81003601ce80 R14: ffff81003d97dc58 R15: 0000000000000004
FS: 00000000410c4960(0000) GS:ffffffff80675000(0000) knlGS:000000007f43fbb0
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 00002b852be473a0 CR3: 000000002885f000 CR4: 00000000000006e0
Call Trace: <ffffffff80161537>{page_check_address+178}
<ffffffff801615e2>{page_referenced_one+108} <ffffffff801616a2>{page_referenced_anon+80}
<ffffffff801617d4>{page_referenced+50} <ffffffff801579aa>{refill_inactive_zone+348}
<ffffffff801575e2>{shrink_cache+122} <ffffffff80127a95>{try_to_wake_up+840}
<ffffffff80157d9a>{shrink_zone+181} <ffffffff80158212>{balance_pgdat+536}
<ffffffff80158475>{kswapd+286} <ffffffff80141c32>{autoremove_wake_function+0}
<ffffffff80141c32>{autoremove_wake_function+0} <ffffffff8013e63b>{worker_thread+0}
<ffffffff8010b6aa>{child_rip+8} <ffffffff80158357>{kswapd+0}
<ffffffff8010b6a2>{child_rip+0}
Dann letzten Freitag das gleiche Phänomen, support angerufen, lakonischer kommentar: es konnte kein Problem festgestellt werden, reboot funktionierte.
Dann gestern der nächste Hänger! Diesmal konnte ich den einzig nützlichen Hinweis auf einen Fehler in /var/log/warn finden:
Code: Select all
Oct 31 14:08:05 s15229400 syslog-ng[1927]: Changing permissions on special file /dev/tty10
Oct 31 14:08:05 s15229400 kernel: swap_free: Unused swap offset entry 00002000
Oct 31 14:08:09 s15229400 kernel:
Oct 31 14:08:09 s15229400 kernel: Call Trace: <ffffffff80151d9f>{bad_page+83} <ffffffff80152684>{free_hot_cold_page+114}
Oct 31 14:08:09 s15229400 kernel: <ffffffff8015a62a>{zap_pte_range+477} <ffffffff8015a8e8>{unmap_page_range+475}
Oct 31 14:08:09 s15229400 kernel: <ffffffff8015aa35>{unmap_vmas+238} <ffffffff8015f8f7>{exit_mmap+114}
Oct 31 14:08:09 s15229400 kernel: <ffffffff8012cd21>{mmput+37} <ffffffff80178c7e>{exec_mmap+704}
Oct 31 14:08:09 s15229400 kernel: <ffffffff801a1dbb>{dnotify_parent+28} <ffffffff80179431>{flush_old_exec+77}
Oct 31 14:08:09 s15229400 kernel: <ffffffff8019a0ca>{load_elf_binary+1244} <ffffffff8017992b>{search_binary_handler+147}
Oct 31 14:08:09 s15229400 kernel: <ffffffff80179c42>{do_execve+383} <ffffffff8010946e>{sys_execve+49}
Oct 31 14:08:09 s15229400 kernel: <ffffffff8010ac17>{stub_execve+103}
Oct 31 14:08:11 s15229400 kernel:
Preisfrage:
* Gibt es andere Ursachen als einen Hardware defekt? Wenn es an der Hardware liegt, wie kann ich 1&1 das beweisen, dass die mich auf einen anderen Server legen?
* Wie zuverlässig ist der Reboot über die 1&1 webseite, klappt das normalerweise?
* Beim googlen bin ich auf "Xen" gestossen, aber wo sollte das auf einem regulären rootserver zum einsatz kommen?
* Falls ich den server wieder neu initialisieren muss, wie kann ich besser tracen, was passiert, bevor er abstürzt?
Danke für Eure Hilfe, so langsam verzweifle ich.