Posts Tagged ‘Preload’

Now that Ubuntu is looking perfect on my desktop (well, sort of!), it’s time to make sure it’s running nicely, too. Here, then, are a couple of safe and modestly effective performance tuning tweaks for Ubuntu (actually, come to think of it, for pretty much any Linux distro!)

I mentioned a while back that when I reboot, I can get a functional desktop in about seven seconds, which is plenty fast enough I suppose! But to really make things snappy after the PC’s up and running, it’s possible to prelink and preload. Programs will often make use of shared libraries to function properly -and those libraries are often loaded into memory as-and-when the program needs them (which process is called dynamic linking… and, in the land of Windows, is what gives us DLLs, or dynamic linked libraries, their name). The problem with dynamic linking is that you never know between each run of a program which bit of memory your shared libraries will be loaded into, so there’s a performance hit whilst the program finds out. Prelinking aims to load the libraries in advance into memory locations that are fixed (more or less) between each run of a program -and, having done that, the program itself can look up those locations just once, on its first load. Thereafter, things should be (moderately) snappier.

It’s very easy to do. In a terminal, issue the command sudo aptitude install prelink. When that’s complete, issue the command sudo gedit /etc/default/prelink and change the line which currently reads ‘PRELINKING=unknown’ to read ‘PRELINKING=yes’. Finally, schedule the thing to search for libraries suitable for prelinking by issuing the command sudo /etc/cron.daily/prelink.  And that’s the job finished.

As for preloading… well, I can’t really improve on the explanation of it in Wikipedia! It’s a little daemon that tries to load oft-needed files into memory when nothing much else is running, and since those files will then be found in memory when they’re eventually required, things should be a little faster than before. Again, dead easy to install: sudo aptitude install preload. And that’s all there is to do.

Finally, for this time at any rate, there’s the good old swappiness setting to tweak. ‘Swappiness’ is the tendency of a Linux PC to page things out of memory down to the hard disk. At its maximum setting of 100, the PC will aggressively swap stuff that’s sitting in RAM out to disk. At its lowest setting of 0, the PC will be extremely reluctant to page things out -meaning that more stuff gets left in RAM (where, we hope, accessing it again will be lightening fast). Putting into words of almost one syllable, therefore: the higher your swappiness setting, the more keen your PC will be to page to disk. Ubuntu ships with a default swappiness setting of 60, which seems a tad high to me. It’s therefore another easy performance tweak to issue the command gedit /etc/sysctl.conf and then add a new line to the end of the file that reads vm.swappiness=0 -or whatever other value you prefer, of course! That new setting doesn’t take effect until you reboot, though. To get the new setting to take effect immediately, you additionally have to do the following:

sudo su
echo 0 > /proc/sys/vm/swappiness

(And note that merely doing sudo echo 0 > /proc/sys/vm/swappiness simply produces a ‘permission denied’ error. You have to do the sudo su bit first so that you are issuing the echo command as root, not as a normal user with sudo privileges)

I should add that the subject of swappiness can provoke something akin to religious war! There’s a good debate to be read here, for example. Good points are made on both sides, including this one:

I don’t know. What if you have some huge application that only
runs once per day for 10 minutes? Do you want it to be consuming
100MB of your memory for the other 23 hours and 50 minutes for
no good reason?

If swappiness was high, in other words, then a huge run-once application would do its stuff and then be paged out of RAM. Having just switched swappiness down to nothing at all, though, I will find that such a run-once-monster application continues to consume RAM. Or, as Andrew Morton (kernel-maintainer-in-chief) himself puts it:

You really don’t want hundreds of megabytes of BloatyApp’s
untouched memory floating about in the machine. Get it out on the disk,
use the memory for something useful.

So, your mileage might well vary – and you’ll be in good company if it does: that’s all I’m saying! For me, a setting of zero works well, especially since I have 8GB of RAM to work with, so if I do ever have BloatyApp sticking around for too long, I probably won’t notice it. The other factor that makes me keen on very low swappiness is that I’m booting off a solid state hard disk. On the one hand, using a SSHD would mean that even if something did get swapped out to disk, I could re-access it with near RAM-like speeds, so a swappiness of 100 would perform almost as well as one of zero. But, on the other, it is unfortunately true of the current generation of SSHDs that if they are written to a lot, they wear out quickly -so avoiding ’swap writes’ might help make my hard disk last longer. Although the tendency of SSHDs to wear out through excessive writes can be exaggerated (it takes a LOT of extra writes!), I do tend to side with the ‘turn down swappiness in the presence of SSHDs’ school, so I’m sticking with my zero setting!