Speed up boot and application start times and general responsiveness on a desktop/laptop (i.e. not a server or console based system)
Debian, at default settings, boots rather slowly compared to some other distros and operating systems. The start up time of larger desktop applications such as OpenOffice.org Writer, Firefox/Iceweasel is somewhere between slow and glacial. And once opened, the responsiveness of applications can sometimes leave a lot to be desired.
Can we fix it? Yes we can!
Requirements
This howto uses only applications available from Debian main repository, for Lenny and newer. You'll need a package manager, a net connection, a terminal emulator and 5 or 10 minutes of your time. No other tools are needed. No special knowledge is assumed though some familiarity with Debian in general is assumed. You should follow good practice and be able to back up and restore files and directories in case disaster strikes. I'm going to use apt-get in my examples because everyone has got it and it's what I'm familiar with. You can just as well use Synaptic, aptitude etc.
You will see some warnings/advisories generated by dpkg and/or shown in package descriptions (if you read them). It is up to you to read them and make your own decisions.
I strongly suggest backing up your current configuration before making any changes, to a medium you can easily access if you render your system unbootable. Make sure you know how to restore it. Before I made any changes to my own system I backed up /etc and I can use a live utility CD such as PartedMagic or SystemRescueCD to restore /etc if necessary.
If you hose your system and didn't make a backup, or made a backup and don't know what to do with it, you can tell me all about it if you like but I don't recommend it.
Having said all the scary stuff I can also say that I had no problems of any kind.
Why We Love Debian
There are several ways to speed boot times, application starts and increase general responsiveness for desktop users. By default Debian doesn't use any of them
Boot Speed Up
You've possibly also been bored to tears by Arch fanboys banging the drum about backgrounding services. All it means is that services at boot time don't start entirely sequentially. Sequential starting means that if one process is slow to start then everything subsequent is delayed. The solution is parallel starting (backgrounding) where one service starting slowly doesn't delay the start of other services which don't depend on it.
Another thing you might notice as Debian boots is that some services start/stop/start again (firestarter is an obvious one). This is because the order of the start up scripts doesn't conform to LSB's dependency based order, to which the scripts refer.
So let's get the start up scripts conforming to LSB and also allow parallel startup.
Re-order the scripts:
Code: Select all
# apt-get install insserv
Allow parallel starts:
Code: Select all
# echo 'CONCURRENCY=shell' >> /etc/default/rcS
Readahead
<edit> readahead has been replaced in squeeze by readahead-fedora. This readahead section of the howto is probably not useful or accurate if you run squeeze or newer.</edit>
Which sounds great but I found no benefit. I'm not the only one. It might even add a second or two but I can only suggest trying it on your hardware with your OS.The readahead package runs at boot and populate the kernel disk cache with the files that is going to be needed at boot time. To activate it, install the readahead package, touch the file /etc/readahead/profile-once and reboot once. The profiling boot is very slow, and will tune the list of files loaded to match the list of files used during the profile run.
Code: Select all
# apt-get install readahead
Code: Select all
# touch /etc/readahead/profile-once
Other issues affecting boot speed:
What services are you running? This is up to you and outside the scope of this howto. I'm assuming you don't run cups if you don't have a printer etc etc.
Replacing bash with dash as the default system shell (not log-in shell). This is/was one of the release goals for Lenny. I'm running Lenny fully up to date and /bin/sh is still linked to bash. I'm assuming the change hasn't happened because there are still important scripts which explicitly depend on bash. Try it if you like but stock up on tranquilisers/anti-depressants/bullets/ubuntu CDs first.
Application Start Up Speed
Typically the way to boost responsiveness (apparent performance) on the desktop is to use caching. While the system boots it caches to RAM the files/binaries you're likely to use. There's an excellent package to do this in Debian, called preload. Preload is all about user applications, it is not intended to speed up boot and may do the opposite (very marginally).
Preload runs as a daemon, monitoring what you actually do and adapting to that. It means that initially you see no benefit, but after you've used it for a few days or weeks it makes an unmistakable and significant difference. I've been running it for...err...so long that I'm not sure. I disabled it today and rebooted to see how my applications launched without preloading. It was hideous. Grindingly slow, and this on a Core Duo with 1.5GB DDR2. OpenOffice Writer took so long to start that I'd rolled a cigarette and put the kettle on before it was up. I re-enabled preload and rebooted. Writer fired up in a couple of seconds. Preload imo is not an option but a necessity on desktop systems.
Code: Select all
# apt-get install preload
Application/General Responsiveness
caveat: it's been a long time since I installed Debian and I'm not sure what the current fstab defaults are. This section may be superfluous now.
A huge hit on performance on Linux based OSs has been the way file and directory access times are recorded. Basically every time you merely access a file or directory, even cached, (just read it, not even modify/write to it) the access time is written to disk. I'll quote Ingo Molnar, he's Linus Torvald's right hand man on the kernel team:
Luckily the solution is very easy, a quick edit of /etc/fstab in order to add either the noatime or the relatime flag. If you use noatime you don't need to also use nodiratime. Lots of people do this, and recommend it, but it's silly because nodiratime is anyway a subset of noatime.I cannot over-emphasize how much of a deal it is in practice. Atime updates are by far the biggest IO performance deficiency that Linux has today. Getting rid of atime updates would give us more everyday Linux performance than all the pagecache speedups of the past 10 years, _combined_.
It's also perhaps the most stupid Unix design idea of all times. Unix is really nice and well done, but think about this a bit: 'For every file that is read from the disk, lets do a ... write to the disk! And, for every file that is already cached and which we read from the cache ... do a write to the disk!'
Example:
change this:
Code: Select all
/dev/sda1 / ext3 defaults,errors=remount-ro 0 1
/dev/sda3 /home ext3 defaults 0 2
Code: Select all
/dev/sda1 / ext3 defaults,noatime,errors=remount-ro 0 1
/dev/sda3 /home ext3 defaults,noatime 0 2
There are two more easy fixes to make your system more responsive. By default the Linux kernel swaps data and applications to disk in order to free RAM. It does it really well but if you run a desktop it might make you want to scream or lie down in a darkened room. On the desktop you want (perceived) application responsiveness to be prioritised. For example could you care at all if you unzip a huge file (while getting on with other tasks) and it takes 100 seconds as opposed to 95 seconds to do this? No, me neither. But how about if now your other applications, or even your entire desktop, take 5 seconds longer to respond, i.e 6 seconds instead of 1 second, or is apparently frozen? Yup, this will drive you nuts. It's fine on servers because there's no desk jockey anxiously waiting to open another tab, play a tune or browse a directory, and data throughput is far more important than pretty much anything. But on a desktop it's truly horrible.
This can be changed in our favour in two ways. First by changing the kernel's paging behaviour. It's done with a simple file edit to /etc/sysctl.conf and adding a value for vm.swappiness. We can choose a value between 0 and 100 where 0 means the kernel tries to keep everything in RAM and not cached to disk and 100 means it aggressively caches to disk to free RAM. The default in Debian is 60, which is OK but conservative. Laptop users should in any case use a low value to reduce writing to disk (because writing to disk negates benefits of power management and runs down your battery very quickly).
Code: Select all
# echo 'vm.swappiness=20' >> /etc/sysctl.conf
Code: Select all
# echo 'vm.vfs_cache_pressure=50' >> /etc/sysctl.conf
Disclaimers and references
Some people, even Debian forums members, will see a howto like this as some kind of evidence that Debian is not a good desktop system. Take a minute to pity/slap them and then remind them that Debian is the Universal Operating System (if you get kidnapped by aliens, they'll be running Debian) and if they want a preconfigured desktop-centric distribution many are available. Debian requires a little configuration and then excels, exceeds all others, goes to warp factor and exterminates/saves entire galaxies (or something).
I've used noatime flag in fstab for ages and it has clear benefits and no downside for desktop users. If you run a mailserver or other application that needs to know access times, or you like to do thorough security audits you should use system defaults or maybe relatime.
Preload: imo brilliant, can't find any problem or drawback in actual use but the software's author does point some out: http://www.techthrob.com/tech/preload_files/preload.pdf You'll see your system's memory footprint increase a little as you use preload. This is a good thing. You bought that RAM to make your computer work fast, not to avoid using it and instead have everything swap out to disk. This is not Windows and we are not doofus Power Users.
vm.vfs_cache_pressure & vm.swappiness
I don't have the technical knowledge to understand every effect these values have on your OS. I've read quite a lot by kernel developers/maintainers/contributors and I certainly didn't understand all (much!) of it. I've also read a lot of other people's writings on the subject and I'm not convinced they do either I welcome any corrections or useful suggestions you may have regarding my understanding or method.
Some useful links:
http://packages.debian.org/lenny/preload
http://www.techthrob.com/tech/preload_files/preload.pdf
http://www.cyberciti.biz/tips/speed-up- ... ystem.html
http://packages.debian.org/lenny/readahead
http://wiki.debian.org/BootProcessSpeedup
Improve the Debian boot process - blog
http://initscripts-ng.alioth.debian.org ... harts.html
http://wiki.debian.org/LSBInitScripts/D ... yBasedBoot
http://packages.debian.org/lenny/insserv
Linux: Replacing atime With relatime
http://rudd-o.com/archives/2007/10/02/t ... -fix-that/