Monday Jan 04, 2010

Speeding up your Linux Guests

With the clock ticking over to a new decade, now would seem to be a good time for a quick blog on timer interrupts in guests and how you can speed up your guests, while also lightening the load on your host, with the judicious use of a bit of guest configuration.

All operating systems make use of a system clock which ticks at a particular frequency. Common Linux distributions use kernels which drive the clock at 100Hz, 250Hz or 1000Hz. You can find out what your Linux kernel is configured for using this command:

grep CONFIG_HZ /boot/config-<kernel>

where kernel is the version of Linux you're running. The result of this command on my Oracle Enterprise Linux installation looks like this:

[root@localhost grub]# grep CONFIG_HZ /boot/config-2.6.18-164.el5
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set

...which tells me that my kernel is configured to use a 1000Hz clock tick.

In a virtualized environment this means that there will be lots of context switches as the host schedules the guest to deal with clock ticks which don't do very much.  And this will become most visible by seeing a relatively high host cpu usage even when the guest is idle. (Note that the exact behaviour also depends on the host system. For example, the same OEL vm runs comfortably on my Mac host, but my Windows host gets very busy running it.)

If you see an idle Linux guest which is configured for a 1000Hz clock using up lots of host cpu cycles, you may want to reduce the clock frequency using the boot time parameter "divider=10". You can do this by adding the parameter manually as the grub boot loader starts, or by editing the grub configuration file as follows:

  1. Edit /boot/grub/grub.conf
  2. Duplicate the existing Title section, and rename it (this means you can choose at boot time which config to use)
  3. Add the "divider=10" parameter as follows:
 kernel /vmlinuz-2.6.18-164.el5 ro root=/dev/VolGroup01/LogVol00 rhgb quiet divider=10

Here is what my complete grub.conf looks like now:


This results in fewer context switches, a lighter host load (as measured by Window Task Manager) and faster guest execution. For example, the speed to boot my OEL vm (on a Windows 7 host) dropped from 115 seconds to 80 seconds which, according to my calculations, is a 30% increase in performance. Not bad for a simple bit of configuration ;-)


Thursday Oct 11, 2007


Most of you may know this already but for those that don't, I thought I'd take a minute to explain a little about SGD and its place in the new VDI market....

Server Based Computing (SBC)

SGD was originally designed to allow people to run local and remote apps side by side in a hybrid desktop model. The remote applications were made to look like local ones (seamless windows), and behave like local ones (printing, filesystem access, audio, etc) but they were actually running on back end server platforms. And most SGD customers use multiple local and remote apps simultaneously, e.g. they'll have several windows open running a mix of Windows, Solaris, Linux, etc. apps

This approach solves issues of data security (lost laptops), manageability (apps live on servers in datacenter) and mobility (use any client from any network location). So administrators can decide which apps should be centrally located and which local on the users PC.

But what if you wanted to deliver not just the apps, but the whole desktop environment too? Well, some SGD users do this today when they publish a full Windows desktop or Gnome-session, say. But traditionally, these have been desktops delivered from Windows Terminal Servers or Solaris/Linux Servers. And the problem with Windows Terminal Server has been that some apps just don't work in a Windows server environment (e.g. they expect a unique IP address or global access to the registry/filesystem, because they were designed to run on a PC).

Virtual Desktop Infrastructure (VDI)

So what is usually meant by VDI is that the desktop environments (usually Windows desktop environments) are not running on servers, but running on Windows \*client\* OSes which are themselves running in individual virtual machines on a server. e.g. Windows XP or Windows Vista instances on, say, VMware ESX Servers.

This is interesting because those misbehaved apps now have a better chance of working because they are running on the platform for which they were designed, a Windows PC.

Now all we have to do is provide secure access to these desktops, and that's what SGD has been doing for years just like this...


So hopefully you can see that SGD is equally applicable for SBC and VDI.

One more thing: if the value you derive from SGD is proportional to the number of apps you access via it, should I pay as much when I use SGD in a VDI environment? After all I'm just delivering a single app - the Windows desktop.

Thankfully, those smart guys in Sun Marketing have delivered a new product for exactly this use case.

When you buy licenses for Sun xVM VDI Software you are allowed to use SGD or Sun Ray Software to deliver a single desktop environment per user.


Fat Bloke


« February 2016