HowTo Speed Up Boot & Increase Responsiveness (Desktop)

Share your own howto's etc. Not for support questions!

HowTo Speed Up Boot & Increase Responsiveness (Desktop)

Postby julian67 » 2008-09-27 17:31

Purpose

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 :lol:

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


Read the warning and go ahead if you like.

Allow parallel starts:

Code: Select all
# echo 'CONCURRENCY=shell' >> /etc/default/rcS


Some people would use CONCURRENCY=startpar instead. They're basically the same thing but shell lets the output print to screen in any old order and is apparently faster.

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>

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.


Which sounds great but I found no benefit. I'm not the only one. It might even add a second or two :shock: but I can only suggest trying it on your hardware with your OS.

Code: Select all
# apt-get install readahead

Code: Select all
# touch /etc/readahead/profile-once


reboot.

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


That's it. It is configurable but the defaults should be absolutely perfect for most people.

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:

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!'


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.

Example:

change this:

Code: Select all
/dev/sda1       /               ext3    defaults,errors=remount-ro 0       1
/dev/sda3       /home           ext3    defaults       0       2


to

Code: Select all
/dev/sda1       /               ext3    defaults,noatime,errors=remount-ro 0       1
/dev/sda3       /home           ext3    defaults,noatime        0       2


and reboot.

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


The second change will affect the way the kernel frees caches of block devices vs filesystem entries. We'd prefer that when the kernel tries to free up cache it gets rid of cached block devices before cached filesystem entries, because having cached filesystem entries makes our filemanagers and other applications much more responsive than if they had to seek everything from the actual filesystem. This time we set a value for vm.vfs_cache_pressure, also in /etc/sysctl.conf. The default is 100, I don't know what the top limit might be but if you choose 0 your system may indulge in a horrible swapfest when handling large files. Try this:

Code: Select all
# echo 'vm.vfs_cache_pressure=50' >> /etc/sysctl.conf


Reboot.

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 :D 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-your-linux-system.html

http://packages.debian.org/lenny/readahead

http://wiki.debian.org/BootProcessSpeedup

Improve the Debian boot process - blog

http://initscripts-ng.alioth.debian.org/soc2006-bootsystem/bootcharts.html

http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot

http://packages.debian.org/lenny/insserv

Linux: Replacing atime With relatime

http://rudd-o.com/archives/2007/10/02/tales-from-responsivenessland-why-linux-feels-slow-and-how-to-fix-that/
Last edited by julian67 on 2010-10-10 20:32, edited 1 time in total.
User avatar
julian67
 
Posts: 4648
Joined: 2007-04-06 14:39
Location: Just hanging around

Postby MeanDean » 2008-09-27 19:03

Good info. Nice to have this all in one place. I already use a few of the suggestions and I may try more of them. I have used dash as default for a long while and I have never ran into a problem.

I would of like to seen some before/after benchmarks for some of the suggestions though.
User avatar
MeanDean
 
Posts: 3956
Joined: 2007-09-01 01:14

Postby julian67 » 2008-09-27 19:23

MeanDean wrote:Good info. Nice to have this all in one place. I already use a few of the suggestions and I may try more of them. I have used dash as default for a long while and I have never ran into a problem.

I would of like to seen some before/after benchmarks for some of the suggestions though.


I didn't benchmark for several reasons:

Inertia

Laziness

My benchmarks mean nothing on someone else's system, particularly the use of readahead and insserv and CONCURRENCY=shell which, I believe, will offer vastly different results depending on the services you run.

Measurement (for me) is more important where differences might be marginal or ascribed to placebo effect. noatime flag and preload offer such obvious differences that you really don't need to measure them to know it's good.

Things like vm.swappiness and vm.vfs_cache_pressure settings, if you measure things, should by definition show "worse" performance in some areas. But "worse" performance of background tasks with the payoff of excellent responsiveness on the desktop is what we want on a desktop system. I think measuring stuff might confuse people. Better to try it and just see the difference. It's why I marked the howto as (Desktop). Much of this stuff would be counter productive or redundant on a server/console based system.
User avatar
julian67
 
Posts: 4648
Joined: 2007-04-06 14:39
Location: Just hanging around

Postby anticapitalista » 2008-09-27 19:50

Nice info Julian67, though on my box some had already been implemented ie noatime, preload.

insserv made very little difference, but I remember initng making a very noticeable difference in the past when I tried it. (it is not in Testing or sid though).

IMO, what really does speed up boot time is the services loaded or not at boot. This is why Arch seems so fast at first as there are hardly any services running and slows down when you add more apps that need services started.

So, if you know which services to disable, you gain a lot of boot speed.
anticapitalista
 
Posts: 234
Joined: 2007-12-14 23:16

Postby julian67 » 2008-09-27 20:26

Thanks

I think insserv works best in conjunction with the concurrency value. I like insserv enough just for the fact it makes the boot process more coherent if you need to actually see what's happening at boot time.

Readahead has never done anything for me except add between 5 and 15 seconds (on different systems) to boot time but I've seen a combination of preload, noatime and the sysctl values make a very obvious and beneficial difference every time. Some distros do some or other of these by default. Zenwalk certainly sets noatime and I think (from memory) a low swapiness value. I think Ubuntu uses/used readahead by default and sets the relatime flag in fstab. gNewSense is about the fastest booting "big DE" based distro I've seen so it might be worth looking at that to see what they do. I have to admit that boot time is not a huge priority for me as long as it's not excessive, but most of the responsiveness tricks impact on boot time so I thought it should all be in there.

It's true about Arch. I like to remember that when someone tells us their PIII boots in 15 or 20 seconds that they're looking at a console with not a lot of useful activity going on......I'll take the extra minute and have internal caching DNS, full desktop environment, tor, privoxy, fuse, ssh-server, 3 instances of tilda+ncurses application, virtualbox services and so on :lol:
User avatar
julian67
 
Posts: 4648
Joined: 2007-04-06 14:39
Location: Just hanging around

Postby Mr B » 2008-09-28 10:24

Thanks for this tuto - works great for my lenny desktop.

Boot up is faster and desktop feels faster and more responsive :D One difference I have noticed is that shut down is a little slower (preload??)

What's the difference between preload and prelink (if any)?? and is one better than the other or can they be used together??
Mr B
 
Posts: 179
Joined: 2008-07-26 15:30

Postby julian67 » 2008-09-28 15:47

Prelink is something I overlooked. You can read about it at http://en.wikipedia.org/wiki/Prelinking

I'm sure it wouldn't be useful on a rolling release like Debian Testing because it relies on libraries not changing too often. It looks like it would be extremely beneficial on a stable release but I don't have one installed, only Testing.

When Lenny becomes Stable I intend to continue to use it for a few months at least before thinking about dist-upgrade to the new testing. I guess I'll try it then and post if it's useful.

I can't see any reason why preload and prelink shouldn't work together very well on a stable release.

Meanwhile here are some useful links:

http://usr-share-man.org/man8/prelink.html

http://web.archive.org/web/20031010172145/http://people.debian.org/~chris/prelink/

http://ubuntuforums.org/showthread.php?t=1971

Shutdown times:

I don't know what might have happened because you don't say which of the changes you actually made.
User avatar
julian67
 
Posts: 4648
Joined: 2007-04-06 14:39
Location: Just hanging around

Postby Mr B » 2008-09-28 19:35

Apart from "readahead" I've done it all.
I've tried changing the "swappiness" before without much noticeable effect, but configuring how the caching is handled and "noatime" seem to make a real difference.

At shutdown, there is a black screen with mouse pointer for a few seconds before the kdm closes... Not serious or a problem, just an observation. I assumed it was preload saving it's data?
Mr B
 
Posts: 179
Joined: 2008-07-26 15:30

Postby julian67 » 2008-09-28 19:51

Sorry, not sure. I don't notice this on my systems (no KDE).
User avatar
julian67
 
Posts: 4648
Joined: 2007-04-06 14:39
Location: Just hanging around

Postby didi » 2008-09-28 20:49

Do the swappiness and vfs_cache_pressure settings have an effect if you're not using swap space, or only when you are using it?
I have 3GB RAM, so don't expect any swapping anytime soon.

I've only applied the preload thing thus far, but haven't yet noticed a difference, but it's only been a day now.
Testing (server) + Unstable (workstation) 32-bit on AMD Athlon64 X2
didi
 
Posts: 909
Joined: 2007-12-04 16:26
Location: the Netherlands

Postby julian67 » 2008-09-28 21:16

didi wrote:Do the swappiness and vfs_cache_pressure settings have an effect if you're not using swap space, or only when you are using it?
I have 3GB RAM, so don't expect any swapping anytime soon.

I've only applied the preload thing thus far, but haven't yet noticed a difference, but it's only been a day now.


Probably not but it depends what you do. I have a system with 768 MB RAM and another with 1 GB and another with 1.5 GB. Even the 1.5 GB system will occasionally swap to disk, usually if I'm doing multilayered graphics editing of large files. If you edit very large files like video files, .iso images etc then you might see the same.

The big differences on a system with plenty of RAM are going to come from the noatime flag and preload. If you apply the noatime flag and reboot you'll see the difference immediately. With preload a nice illustration might be to switch it off in a few weeks time and reboot. Any doubts about its effectiveness will vanish while you listen to your HDD seeking and watch the animated gif struggle slowly across the splash the first time you start up OOo.

You know how much faster applications load when they've already been opened before in the session? Like Iceweasel opening in 2 seconds instead of 15 for example? Preload will give you that snappy performance but on first time starts on all your commonly used applications. But it does take a little while. I guess the longer you use preload the more accurately it maps your habits and the more effective it is.
User avatar
julian67
 
Posts: 4648
Joined: 2007-04-06 14:39
Location: Just hanging around

Postby didi » 2008-09-28 21:40

I want to try the noatime setting too, but not before I've figured out what the (negative) consequence of it is.
I guess there is a reason it's in there and still not removed from the kernel.
And I guess it needs some extra time for preload to get my habits and act on it. And it's time I start installing the programs still missing on my system, like OO, and start using them :lol:
One of the reasons I tried it, is because I think Iceweasel is taking too long to start up, although it surely isn't 15 secs on my machine. And I haven't noticed much/any difference in it's startup time, so I'm also not getting 2 secs.
But I'm pretty confident that preloading will improve the systems (perceived) performance, just like I noticed it when Mozilla (old suite) started doing preloading.
Testing (server) + Unstable (workstation) 32-bit on AMD Athlon64 X2
didi
 
Posts: 909
Joined: 2007-12-04 16:26
Location: the Netherlands

Postby julian67 » 2008-09-28 22:05

didi wrote:I want to try the noatime setting too, but not before I've figured out what the (negative) consequence of it is.


There's no negative consequence unless you have applications that depend on access times to work. This is unlikely on a server and on your desktop is not even worth worrying about.

The traditional default is atime, which means every instance of a file/directory (even from cache) being accessed = a write to disk. As long as there are writes in progress then reads are slowed, as well as writes that you actually want to make. That is dumb because it means your HDD is constantly being written to, it never spins down, it kills HDD performance, HDD lifespan, system responsiveness, negates the read/write performance of modern drives and their power management and if you're a laptop user it kills your battery too. It's just horribly stupid, a relic from the past.

Some distros use noatime by default and most have now moved to using relatime by default .
User avatar
julian67
 
Posts: 4648
Joined: 2007-04-06 14:39
Location: Just hanging around

Postby MeanDean » 2008-09-29 00:18

didi wrote:I want to try the noatime setting too, but not before I've figured out what the (negative) consequence of it is.
I guess there is a reason it's in there and still not removed from the kernel.

Actually, there was a discussion not long ago about it and I think the agreement was that it is truly a relic. I think it was concluded that there was one (or maybe two) software packages that expected atime to be used. They were obscure packages if I remember correctly. I have used noatime for about a year now - no problems here.
User avatar
MeanDean
 
Posts: 3956
Joined: 2007-09-01 01:14

Postby MeanDean » 2008-09-29 00:21

julian67 wrote: Like Iceweasel opening in 2 seconds instead of 15 for example?

I never seen much difference with preload but I have only tried it with my newer systems. Maybe on a older system??? Even openoffice and firefox start up in a couple seconds the first time, well openoffice may take a little longer but not much.
User avatar
MeanDean
 
Posts: 3956
Joined: 2007-09-01 01:14

Next

Return to Docs, Howtos, Tips & Tricks

Who is online

Users browsing this forum: No registered users and 4 guests

fashionable