TYPO3 hogging
Posted on Monday, 7th April, 2008 in Life
Well, we do appear to be having some strange load problems with our main TYPO3 box hosting several home pages of the local universities, as you can see below.
LOAD on t3node1 between 05:00-19:00 on 2008/04/07
We repeatedly tried to figure out which of them was the one responsible, but neither I nor the other Unix sysadmin knew a better way to figure out the load each TYPO3 installation was causing (since there ain’t no phptop or something similar). But since today the new semester started, we figured it might be good to finally figure which one it was. And a few minutes (as in one or two) wouldn’t be much of a problem compared to the advantage we’re getting out of it.
As a comparison, here’s the “normal” load for the last week:
LOAD on t3node1 between 2008/03/31 and 2008/04/07
So as a last resort (because of said load problems), we simply deactivated one vHost after another, until the load started to relax. Unsurprisingly it was one of the installations that had problems before. Let’s see whether or not the people over at said university are insightful or not … 
OCFS2 follow-up
Posted on Friday, 7th March, 2008 in Life
OK, it turned out that said collegue wasn’t responsible at all. Turns out, the *real* trigger was me creating a new volume on our SAN, on the same array that houses the OCFS2 volume.
Apparently, during creation of an additional SAN volume, all other SAN volumes in this array are either read-only or delayed during that time, as you can see from the following log:
kernel: (13,3):o2hb_write_timeout:242 ERROR: Heartbeat write timeout to device sdd1 after 12000 milliseconds kernel: Heartbeat thread (13) printing last 24 blocking operations (cur = 4): kernel: Heartbeat thread stuck at waiting for read completion, stuffing current time into that blocker (index 4) kernel: Index 5: took 0 ms to do submit_bio for read kernel: Index 6: took 0 ms to do waiting for read completion kernel: Index 7: took 0 ms to do bio alloc write kernel: Index 8: took 0 ms to do bio add page write kernel: Index 9: took 0 ms to do submit_bio for write kernel: Index 10: took 0 ms to do checking slots kernel: Index 11: took 0 ms to do waiting for write completion kernel: Index 12: took 2002 ms to do msleep kernel: Index 13: took 0 ms to do allocating bios for read kernel: Index 14: took 0 ms to do bio alloc read kernel: Index 15: took 0 ms to do bio add page read kernel: Index 16: took 0 ms to do submit_bio for read kernel: Index 17: took 0 ms to do waiting for read completion kernel: Index 18: took 0 ms to do bio alloc write kernel: Index 19: took 0 ms to do bio add page write kernel: Index 20: took 0 ms to do submit_bio for write kernel: Index 21: took 0 ms to do checking slots kernel: Index 22: took 0 ms to do waiting for write completion kernel: Index 23: took 2004 ms to do msleep kernel: Index 0: took 0 ms to do allocating bios for read kernel: Index 1: took 0 ms to do bio alloc read kernel: Index 2: took 0 ms to do bio add page read kernel: Index 3: took 0 ms to do submit_bio for read kernel: Index 4: took 9995 ms to do waiting for read completion kernel: (13,3):o2hb_stop_all_regions:1682 ERROR: stopping heartbeat on all active regions. kernel: Kernel panic - not syncing: *** ocfs2 is very sorry to be fencing this system by panicing ***
OCFS2 fun
Posted on Thursday, 6th March, 2008 in Life
Turns out, that said colleague has been playing with NFS on one off the web nodes, thus apparently rendering the remaining nodes offline (or semi-offline).
Now after all web nodes hung themselves, we had to hard reset them, now everything is tingly again .. *yay* for a great first day …