Wie: Absturzsursache bei 1&1 L64 Rootserver feststellen?

FreeBSD, Gentoo, openSUSE, CentOS, Ubuntu, Debian
skyscrap
Posts: 18
Joined: 2006-11-02 00:22

Wie: Absturzsursache bei 1&1 L64 Rootserver feststellen?

Post by skyscrap » 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:

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}
Und auch ein login über die serielle Konsole hat ein paar Fehlermeldungen zu Tage gefördert:

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}
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:

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:
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.

aubergine
Posts: 471
Joined: 2005-09-10 17:52
Location: Frankfurt am Main

Re: Wie: Absturzsursache bei 1&1 L64 Rootserver feststellen?

Post by aubergine » 2006-11-02 01:49

Ich würde mich mit dem Ding erst garnit lange befassen.

Du hast einen Vertrag mit 1und1 welcher besagt das du einen funktionsfähigen XY Server anmietest und dafür xy€ zahlst.

Achso nochwas: Steht in den AGB das jeder Mieter ein Vollprofi in kernel logs und Hardware defekt Analysis sein muss? Ich denke eher nicht, deswegen sag dem Supporter das Ding ist kaputt und die sollen schleunigst was tun.

skyscrap
Posts: 18
Joined: 2006-11-02 00:22

Re: Wie: Absturzsursache bei 1&1 L64 Rootserver feststellen?

Post by skyscrap » 2006-11-02 07:15

aubergine wrote:Ich würde mich mit dem Ding erst garnit lange befassen.

Du hast einen Vertrag mit 1und1 welcher besagt das du einen funktionsfähigen XY Server anmietest und dafür xy€ zahlst.

Achso nochwas: Steht in den AGB das jeder Mieter ein Vollprofi in kernel logs und Hardware defekt Analysis sein muss? Ich denke eher nicht, deswegen sag dem Supporter das Ding ist kaputt und die sollen schleunigst was tun.
:-k Vermutlich hast du recht. Die Sache ist halt, dass ich ungern behaupte das Ding sei kaputt, wenn letztendlich ich (irgendwie) Schuld bin, dass sich der Server immer aufhängt (zu wenig RAM? ...?). Zudem dann ja auch, wenn ich auf neuer Hardware bin, das gleiche Problem früher oder später wieder auftreten wird.

Danke für Deine Meinung :!: :-D

djcrackman
Posts: 207
Joined: 2005-06-02 11:58

Re: Wie: Absturzsursache bei 1&1 L64 Rootserver feststellen?

Post by djcrackman » 2006-11-02 08:31

Mein Tipp: RAM oder HDD.

Arbeitest du mit einer RAID-Lösung?

skyscrap
Posts: 18
Joined: 2006-11-02 00:22

Re: Wie: Absturzsursache bei 1&1 L64 Rootserver feststellen?

Post by skyscrap » 2006-11-02 08:35

djcrackman wrote:Mein Tipp: RAM oder HDD.

Arbeitest du mit einer RAID-Lösung?
Hast du auch einen Tipp, wie ich das näher eingrenzen kann? Es ist ein RAID-System.

>> 1 & 1 Root Server L64

djcrackman
Posts: 207
Joined: 2005-06-02 11:58

Re: Wie: Absturzsursache bei 1&1 L64 Rootserver feststellen?

Post by djcrackman » 2006-11-02 09:27

Soft- oder Hardware RAID?

memtest86 über den gesamten RAM laufen lassen. Würde ich mit folgenden Parametern machen: 8-2-3-3-3 (Zahlenfolge im config-Menü nacheinander eingeben). Wenn nach 5 Durchläufen kein Fehler auftritt, dann dürte der RAM tatsächlich OK sein.

Hast du die Möglichkeit die Kiste mal 7 Tage idlen zu lassen (also ohne CVS und Application Server)?

skyscrap
Posts: 18
Joined: 2006-11-02 00:22

Re: Wie: Absturzsursache bei 1&1 L64 Rootserver feststellen?

Post by skyscrap » 2006-11-02 16:01

djcrackman wrote:Soft- oder Hardware RAID?
Gute Frage, keine Ahnung ehrlich gesagt. Wie sieht man das? Ich seh halt eine Anzahl Partitionen: /sda1 ... /sda8 und /sdb1 ... /sdb8 und /md1 .. /md8, deshalb hätte ich jetzt mal auf ein HW-RAID getippt.
djcrackman wrote:memtest86 über den gesamten RAM laufen lassen. Würde ich mit folgenden Parametern machen: 8-2-3-3-3 (Zahlenfolge im config-Menü nacheinander eingeben). Wenn nach 5 Durchläufen kein Fehler auftritt, dann dürte der RAM tatsächlich OK sein.
Ich hatte memtest nur mit einem Parameter aufgerufen: 500M. Und das obwohl der Server eigentlich 1GB RAM hat, aber dadurch dass das rescue system halt einen großen teil als virtuelle platte nutzt, kann ich den ja schlecht testen (oder??). Die fünf parameter musste ich aber nirgendwo eingeben, was muss ich da anders machen?
djcrackman wrote:Hast du die Möglichkeit die Kiste mal 7 Tage idlen zu lassen (also ohne CVS und Application Server)?
Eigentlich schlecht, weil wir extra deswegen von einem virtuellen auf einen root-server umgezogen sind. Aber wenns der sache dienlich ist, klar.

mattiass
Userprojekt
Userprojekt
Posts: 608
Joined: 2005-12-16 17:57

Re: Wie: Absturzsursache bei 1&1 L64 Rootserver feststellen?

Post by mattiass » 2006-11-02 16:06

SkyScrap wrote:
* Wie zuverlässig ist der Reboot über die 1&1 webseite, klappt das normalerweise?
Mit allerhöchstens ein paar Minuten Verzögerung.
* Beim googlen bin ich auf "Xen" gestossen, aber wo sollte das auf einem regulären rootserver zum einsatz kommen?
Xen ist eine feine Sache, aber wenn das eingesetzt würde, wüsstest Du es.

Hast Du schonmal die SMART-Werte ausgelesen? Möglicherweise sind einige Blöcke der Platte dort defekt, wo Swap liegt. Ausgelagerte Seiten werden falsch oder gar nicht wieder geladen. Sollte aber AFAIK nicht für einen Totalabsturz reichen, es sei denn "init" wird geswappt...

skyscrap
Posts: 18
Joined: 2006-11-02 00:22

Re: Wie: Absturzsursache bei 1&1 L64 Rootserver feststellen?

Post by skyscrap » 2006-11-02 17:17

Hallo,

der RAM wurde jetzt ausgetauscht. Hoffentlich behebt das die Fehler. Jetzt soll ich noch den lilo mbr neu schreiben lassen, der wär wohl defekt.

Danke für die freundliche Hilfe!