I’ve been enjoying our server at UK2.net. It’s a pretty speedy machine (although a little light on RAM - I suspect that they don’t want people running Xen), and it’s connected to a fat pipe. But I’ve been experiencing a lot of bad lockups.

I traced the problem to postmaping the uceprotect.net RBL file. They recommend that you rsync this file from them, and then postmap it into a fast lookup database for postfix, rather than using their DNSRBL service. But running the postmap was taking my box 40 mins. The same operation, on a loaded, lower-spec, 2 year old server took 2 mins (yes this server also has RAID1 on the volume concerned). On my UK2 box, while the postmap was running, the machine became totally unresponsive, and it could take a minute or two to log in, serve a web page, or even execute a basic command like ps.

Clearly something wasn’t right. And it was something in the IO system. The only answer is the 3ware RAID controller. (It’s a 8006-2, doing RAID-1) I know these controllers have a big buffer, so I looked up the 3ware website, for tuning guidance. I followed it to the letter, and things didn’t really improve. I tried the deadline scheduler, and tweaking the buffers, but it only got marginally better.

Personally, I’ve always used software RAID, even for RAID-5, and I’ve never had bad performance like that. And having the RAID in a portable format has really helped with recovery in the past. I understand that Windows monkeys have to use hardware RAID (because their software RAID sucks so much), but is this kind of performance normal?

I’ve asked UK2 to chuck my controller and give me software RAID :-)

Update

I’ve now got software RAID 1, and postmap runs in 25 seconds. That’s what I call a 60x speed improvement :-)

Oh, and the system is totally responsive while the postmap runs.

I thought apt-cacher was an improvement on apt-proxy. Boy was I wrong. It’s been giving me a lot of headaches. Whereas apt-proxy needed the odd restart, apt-cacher needs files to be deleted from it’s cache every now and then…

What a pain.

Now I’ve switched back to apt-proxy, and with a bit of squid tweaking (so that local network traffic isn’t cached, or passed to the SAIX proxy) everything is working well again.

I decided I wanted a 64bit kernel for my UK2 server (seeing as it’s an Athlon X2, and I wanted an ubuntu amd64 chroot to work on it).

After a little playing around, this is how you do it:

• Get your kernel
• Extract it
• make menuconfig ARCH=x86_64
• Create some linux-amd64-gcc, linux-amd64-ld, etc. wrappers. Some need -m64 options. Others autodetect what’s required. (I made a tarball of my wrappers, but they’ve been lost.)
• CONCURRENCY_LEVEL=4 make-kpkg --append-to-version '-londonpride' --revision '1.00' --rootcmd fakeroot --arch amd64 kernel_image
• Extract the control.tar.gz from the deb, edit control file, and change the architecture to i386.
• Install

Unfortunaly, in the week after this, my machine died of disk corruption. This is the 2nd time it’s happened. I hope UK2 don’t use dodgy hardware…

After reading an article about using aptitude properly, I decided that it’s time to make the switch from apt-get. Sure, on some really low memory systems, running aptitude isn’t an option, but for most machines, keeping track of which packages were installed as dependancies really helps keep a system trimmed.

I didn’t like the way that the author did it, I opted for a variant of one of the comments:

While rather a monster command, it does a good job of selecting things that were probably installed as dependancies. If you see anything in the list of things to be removed that you want to keep, you just add in an !~npackagename. Then after that, I run aptitude, limit to ~i!~M (installed, but not automatically) and mark everything that should be a dependancy with M.

Then, it’s simply a case of only ever using aptitude, and your system will be kept nice and clean :-)

Aptitude search patterns are really powerful, instead of having to do the whole dpkg -l | grep ^r type mission, you can just do aptitude search '~c'.

OK. I’ve switched over to a reasonable looking non-default theme. (Although I’ll still write my own at some point…)

My personal tastes would have preferred a flat-file based bloging system. But none of the ones out there seem to come close to Wordpress in terms of features, or style (technical style, naturally)

And I’ve decided that Wordpress’ built in HTML markup-er sucks big time. Markdown, on the other hand, is fantastic. I can’t believe that it’s gone from being the default in the past to being left out of the distribution entirely these days… Tsk tsk