Typo3

I’m coming back today from a six day vacation in the warm south (that is Stuttgart), back at work and find three sheets of paper on my desk. Two tell me something I haven’t done yet, the other one tells me something I haven’t seen yet. One of my colleagues had to restart one of our web nodes and now the thing can’t mount the logging volume (and thus, logrotate / awstats failed to do it’s job). OCFS2 ain’t spitting any error messages, when trying to mount the volume you see it joining the domain the volume belongs to on the other nodes, so from a first glance at things .. nothing is wrong ? ...

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

OK, it turned out that said colleague 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: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 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 ***

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 …

Well, I happen to be back at my favorite application. Today I stumbled upon a " nice" thing. If you turn on the Zend Optimizer (doesn’t matter whether it is 2.6.2 or 3.3.0), one of the TYPO3 back ends ain’t showing any content in the preview pane. Once you turn the Zend Optimizer stuff off, it works without a problem. O RLY ? And as Zend stated on their " Support Forum", they don’t really support the Zend Optimizer stuff in the first place. Which is nice, what for do you need the Zend Guard shit in the first place ?? ...

Well, it’s been quite a while since most of the people last heard a word from me. The last few months I’ve been extremely busy with work-related tasks (and as a side-effect of that, didn’t want to spend much time in front of the computer after 9 hours of work). I also started spending more and more time in the gym, like nearly two hours every Tuesday and Thursday. I finally fixed our replication issues, we do now have a working! MySQL Multi-Master ( 1. Node, 2. Node -- bear in mind, this boxes are only serving MySQL and nothing else, so don’t use these configurations on mixed setups) Replication Setup as database back end for our TYPO3-vHosts. all the web nodes are now serving the content from a clustered, shared SAN volume (is that a good thing ? 😛 - don’t know yet …) our VI environment is getting more and more acceptance (even if you hear some complaints now and then, like “awww, damn that crap my 4GiB RAM, 2x3.0GHz Windows 2008 is running soooo choppy” - simple answer, don’t use Windows Server 2008 and/or Windows Vista!) I finished prepping our VM templates (at least the Windows ones) we’re still putting together the plans on whether or not invest into a VDI solution. The next few weeks are gonna be as frantic as the weeks before, I still have to migrate a lot of TYPO3 installations to our new cluster (which sadly needs time, as we need to wait for DNS changes to propagate). Honestly, I might be ending up extending the SAN volume for the MySQL data storage, as even with only three somewhat busy sites, the binary log of the last 5 days is about 2GiB in size. And we still have ~ 20 other busy sites on a separate box. ...

Apparently the TYPO3 version we are using, doesn’t play too nice with the MySQL MasterMaster replication. Sometimes, something like this is going to happen: 1 2 070826 0:44:32 [ERROR] Slave: Error 'Duplicate entry '75-222419149' for key 1' on query. Default database: 't3nb'. Query: 'INSERT INTO cache_pagesection 070826 0:44:32 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'dbc-mysql1.000192' position 611861372 Well, as you can see from the last line in the log, the Slave-SQL thread found a duplicate entry and thought it is smart to just turn off the thread instead of disregarding the just made entry. So from now on, both databases drift since there ain’t no replication anymore until someone kick starts the replication again (someone being me). ...

Once again, I’m compelled to play (other call it administering 😛) with our TYPO3 cluster (which is sadly running SLES). One thing I just learned about SLES (for the ones curious, its Novell’s SuSE Linux Enterprise Server and yes, it suffers the same pain as SuSE/openSuSE). They split one single config file (at least the apache2 one) into 9 (or more) different files. Another thing is, for what the hell does a simple LAMP need a full blown Xorg w/ KDE installed ? ...