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.
