Allgemein

Ich hab es seit Tagen, dass meine Server, die über VMWare Virtualisiert sind einen hohen Load-Wert haben, ohne dass sie effektiv eine Auslastung haben. CPU ist bei 0-5% und RAM wird nicht mehr als üblich in Anspruch genommen. Auch die IO-Wert der Festplatten sind in Ordnung. VMWare selbst, bzw. das vSphere, zeigt auch nichts auf. Erst schob ich es darauf, dass evtl. viel Spam per Mail reinkommt oder eine Seite mehr als sonst üblich genutzt wird.

Nun habe ich auf eine Server, der sehr wenig genutzt wird, festgestellt dass während der Hohen Load-Werte weder Mails, noch Webanfragen aufliefen, was mich verwundert hat. Ein Blick in die /var/log/syslog verriet mir:

kernel: [14105353.642702] BUG: soft lockup - CPU#3 stuck for 69s! [ksoftirqd/3:13]
kernel: [14105353.642982] Modules linked in: xt_multiport iptable_filter ip_tables x_tables vsock vmmemctl pvscsi acpiph
p loop snd_pcm snd_timer snd vmci soundcore i2c_piix4 container psmouse snd_page_alloc serio_raw shpchp i2c_core evdev pcspkr parport_pc pci_h
otplug button ac processor parport ext3 jbd mbcache vmxnet sd_mod crc_t10dif sg sr_mod cdrom mptspi ata_generic mptscsih mptbase floppy e1000 
scsi_transport_spi ata_piix libata scsi_mod thermal thermal_sys [last unloaded: scsi_wait_scan]
kernel: [14105353.643010] CPU 3:
kernel: [14105353.643011] Modules linked in: xt_multiport iptable_filter ip_tables x_tables vsock vmmemctl pvscsi acpiph
p loop snd_pcm snd_timer snd vmci soundcore i2c_piix4 container psmouse snd_page_alloc serio_raw shpchp i2c_core evdev pcspkr parport_pc pci_h
otplug button ac processor parport ext3 jbd mbcache vmxnet sd_mod crc_t10dif sg sr_mod cdrom mptspi ata_generic mptscsih mptbase floppy e1000 
scsi_transport_spi ata_piix libata scsi_mod thermal thermal_sys [last unloaded: scsi_wait_scan]
kernel: [14105353.643033] Pid: 13, comm: ksoftirqd/3 Not tainted 2.6.32-5-amd64 #1 VMware Virtual Platform
kernel: [14105353.643035] RIP: 0010:[<ffffffff81048027>]  [<ffffffff81048027>] finish_task_switch+0x44/0xaf
kernel: [14105353.643042] RSP: 0018:ffff88013facfda0  EFLAGS: 00000282
kernel: [14105353.643044] RAX: ffff88013fa9e318 RBX: 0000000000000000 RCX: ffff88013fa9e2e0
kernel: [14105353.643046] RDX: 00000000000116e0 RSI: 0000000000000003 RDI: ffff88013fa9e2e0
kernel: [14105353.643047] RBP: ffffffff8101166e R08: ffff88013face000 R09: ffff880005395780
kernel: [14105353.643049] R10: 00007fd29a2b4b60 R11: 0000000000000202 R12: ffff88013fa9e2e0
kernel: [14105353.643051] R13: ffffffff8100f5e7 R14: 0000000000000000 R15: ffff88000538fd00
kernel: [14105353.643053] FS:  0000000000000000(0000) GS:ffff880005380000(0000) knlGS:0000000000000000
kernel: [14105353.643055] CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
kernel: [14105353.643056] CR2: 00007f5180c1d4c6 CR3: 000000013ebad000 CR4: 00000000000006e0
kernel: [14105353.643060] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
kernel: [14105353.643064] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
kernel: [14105353.643065] Call Trace:
kernel: [14105353.643070]  [<ffffffff812fa814>] ? thread_return+0x4e/0xe0
kernel: [14105353.643073]  [<ffffffff8101184e>] ? reschedule_interrupt+0xe/0x20
kernel: [14105353.643076]  [<ffffffff8101184e>] ? reschedule_interrupt+0xe/0x20
kernel: [14105353.643078]  [<ffffffff8104a7f3>] ? __cond_resched+0x1d/0x26
kernel: [14105353.643080]  [<ffffffff812fa9cb>] ? _cond_resched+0x24/0x30
kernel: [14105353.643084]  [<ffffffff8105372e>] ? ksoftirqd+0x60/0xcf
kernel: [14105353.643086]  [<ffffffff810536ce>] ? ksoftirqd+0x0/0xcf
kernel: [14105353.643088]  [<ffffffff81064a5d>] ? kthread+0x79/0x81
kernel: [14105353.643091]  [<ffffffff81011baa>] ? child_rip+0xa/0x20
kernel: [14105353.643093]  [<ffffffff810649e4>] ? kthread+0x0/0x81
kernel: [14105353.643095]  [<ffffffff81011ba0>] ? child_rip+0x0/0x20

Mit diesem Fehler habe ich google gefüttert und bin dann sehr schnell auf folgenden Bericht gestoßen: http://serverfault.com/questions/336591/how-to-fix-bug-soft-lockup-cpu0-stuck-for-17163091968s

Es gibt scheinbar einen Bug im Kernel 2.6.32, der in Verbindung mit der Virtualisierung auftritt, wenn der Server länger als 200 Tage online ist. Es gibt zwei Möglichkeiten:

  1. Alle 190 Tage neustarten, die in dem Bericht geschrieben. Aller Dings beseitigt dies nicht den Fehler.
  2. Kernel Update.

Da es für Debian 5.0 bzw Squeeze allerdings kein höheren Kernel gibt steht man in einem Produktiven System vor einem kleinem Problem: Downtime.

Aber das war die beste Möglichkeit das System auf aktuelle Füße zu stellen. Und in diesem Zug wurde auch MySQL und PHP auf die aktuellen Versionen gebracht. So kann ich auch endlich die aktuelle Typo3 Version einspielen.

30. Oktober 2012

Hoher Load-Wert ohne CPU-, Ram- oder IO-Auslastung

Ich hab es seit Tagen, dass meine Server, die über VMWare Virtualisiert sind einen hohen Load-Wert haben, ohne dass sie effektiv eine Auslastung haben. CPU ist […]
8. November 2011

CMake und MySQL 5.5

MySQL hat mit der Version 5.5 eine neue Methode eingeführt die Sourcen zu kompilieren. Anstelle von ./configure wird ab sofort ein Programm mit dem Namen CMake […]
22. September 2011

Migrieren von VMWare Server 2 zu ESXi

Kommt man in die Versuchung eine Virtuelle Maschine von VMWare Server 2 zu ESXi portieren zu müssen kann man sehr gut den „VMWare vCenter Converter Standalone“ […]
21. September 2011

PDFLib Lizenz installieren

Hat man eine PDFLib-Lizenz der PDFLib GmbH erworben und möchte diese nun zusammen mit der PDFLib-Bibliothek aktivieren, so ist dies recht einfach. Es muss im Webserver […]