Regular OSX SBBOD (Spinning Beachball of Death) :: FIXED

sbbod-221 Over the past few days I had begun to think that my MacBook Pro was developing a problem. Every so often – and I can’t put my finger on how long, but possibly every 10 minutes or so – no matter what application I was using I would get a Spinning Beachball of Death, or SBBOD. The image to the left is familiar to any Mac OSX user on occasions – sometimes things just do take longer than 5 seconds to achieve and thats when OSX will present you with the beachball in all its glory.

But, you shouldn’t really see it when you’re just browsing web pages. And I was. So I went on the hunt, I googled for causes of the SBBOD, and found lots of great answers, many of which I thought had fixed things and then discovered 9 minutes later that nope, no they hadn’t.

There’s a number of things that can cause a SBBOD, including 3rd party Safari plugins (and it seemed as if Safari was usually what I was running when it occurred, although Mail was exhibiting the issue too, along with other things). One site I discovered advised me to remove the file Database.sqlite3 from ~/Library/PubSub/Database. This tip did seem to improve the startup speed of Safari – though I’m not entirely sure why.

However, the actual fix turned out to be entirely off the MacBook Pro and in fact was on a different machine on the network.

I run a DHCP server (most home users probably just use the broadband router for assigning addresses) as I have a number of virtual machines, along with printers and such like that I prefer to be able to set a fixed address.

The DHCP server had not started up after a restart and as such was not issuing IP addresses. The MacBook Pro was trying to start the networking components, waiting for a response from the DHCP server and when it didn’t receive one in a timely fashion it went ahead and used the previous address that it had been assigned. That’s fair and good, it meant I could get online – part of the ‘It Just Works’ plan I suspect.

But unfortunately it seems that because the IP address hadn’t been properly assigned by the DHCP server, OSX was on occasion attempting to re-validate the settings and that was causing anything that used the network to have to wait until the DHCP request timed out.

Once I restarted the DHCP server, my OSX has been back to it’s awesome self and I’ve seen not even one SBBOD! Wahoo!

The moral of the story: Make sure your DHCP server is running, or manually configure your IP address!

Centos 5 in VirtualBox – High CPU Usage FIXED

CentOS LogoLet me give some background to the problem. You’re running CentOS 5 under VirtualBox, perhaps on OSX Leopard Server or indeed possibly another host operating system. You’ve noticed that even when the guest is utterly idle, the processor on the host is hovering at 50% or above. Or maybe only 20% but really, when the guest is idle, why is VirtualBox using ANY host processor.

I noticed that I don’t have this issue with Ubuntu (can’t remember which version) so I figured it had to be a Linux kernel issue rather than a VirtualBox issue.

After much scouring of Google, and receiving some excellent, but highly convoluted answers such as recompile the guest kernel with CONFIG_NO_HZ=y and CONFIG_HIGH_RES_TIMERS=y (neither of which the kernel with Centos 5 understands) and so I went down the path of recompiling my own CentOS kernel.

But now I have found a very simple answer. Forget about recompiling your own CentOS kernel, you don’t need to. You can simply pass a boot time parameter into the kernel using the grub menu.lst


The problem comes because the CentOS kernel is compiled with the┬áCONFIG_HZ_1000=y and┬áCONFIG_HZ=1000 options. This (I’m told) basically means the kernel is trying to service interrupts at a rate of 1000 per second – which is fair and reasonable on normal hardware. But it makes a lot of extra work for a VM which is virtualising those interrupts. Setting the divider to 10 means you drop the amount of time spent generating interrupts and so the VM has less work to do – hence less processor use on the host.

The full line in /boot/grub/menu.lst for my running kernel now looks like this;

kernel /vmlinuz-2.6.18-164.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet divider=10

I’ve also found since making this change that the guest seems a LOT more responsive and snappy. Odd really since the 1000Hz kernels are meant to be snappier. Oh well, Virtualization is a strange art of its own rulemaking and I’m just a user!

Hope that helps someone else.