HowTo Speed Up Boot & Increase Responsiveness (Desktop)

[gerry]

Historical note about need for atime: when Unix started, computers were still using magnetic core storage. The "read" operation was destructive, so to retain the data it had to be immediately re-written. Don't think we need that these days.....

Gerry

[birdywa]

Should I use noatime on my swap partition?

[julian67]

Should I use noatime on my swap partition?

you can try

no.

You can find references to people doing it but I'm not sure why they bother. Nothing is stored in swap in normal use so there are no directory or file access times to be written there. What advantage anyone expects by using noatime on their swap partition is a mystery to me.

[Swynndla]

My boot time took 1m31s.
Then I installed insserv (and preload and changed vm.swappiness & vm.vfs_cache_pressure) following the instructions given in this nice tutorial.
Boot time now is 1m29s.
So there's wasn't a lot in it for me.

[julian67]

My boot time took 1m31s.
Then I installed insserv (and preload and changed vm.swappiness & vm.vfs_cache_pressure) following the instructions given in this nice tutorial.
Boot time now is 1m29s.
So there's wasn't a lot in it for me.

Of those only the insserv change is aimed at improving boot time. As stated earlier using preload will probably lengthen boot time. It's worth actually reading the howto and the references at the end of it before making changes to your system.

[Swynndla]

As stated earlier using preload will probably lengthen boot time.

Good point. I thought it wouldn't be much because you stated it may only "very marginally" increase the time. I removed preload and timed the boot again and now it's 1m26s. Still not a lot in it for me. I've put preload back on as I want it (and at least I haven't increased the total boot time by doing all this and I've got preload!). Again, nice tutorial. Thanks!

[carolinason]

my boot time is ~16 seconds from a default install on this ~6 year old system, i just don't understand.

[Swynndla]

my boot time is ~16 seconds from a default install on this ~6 year old system, i just don't understand.

I was timing from pressing the power button (& press enter on grub straight away) to the kde login screen appearing with the login box.

Most of the boot time is spent on doing file system checks on old & large reiserfs partitions on several hard drives. I've also got a lot of services that are started up. I guess debian is so customisable that it'd be quite different for each person.

[Kats]

Have anyone tired out Texas Flood Boot before?

http://www.resulinux.forumdebian.com.br/texasfloodweb/

It's currently in a very experimental stage, but I found it to be quite stable considering the warnings. Atleast on my system. It did break gdm for some reason, though. gdm would work as long as I used the system default settings for it and never changed them.

Other than that, texas flood reduced my workstations boot-time from 37.5 seconds to 25. And this was only using texas flood as a boot-speed improver, nothing else.

It's VERY easy to install (deb with a guided install), and even easier to uninstall. One root-command, I think it was texasflood-remove, would revert to whatever I was using before texas flood.

[Swynndla]

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

It's all too easy to feel something that isn't really there, so since I'd been running preload for a month and a half, I decided it was about time to record some times of opening up two apps that I commonly use, so I rebooted, waited a minute just in case, then (using a stopwatch) timed how long one of the apps took to start, and did the same with the other app. Then I uninstalled preload (apt-get remove preload), and rebooted, and timed the apps again. There didn't seem to be any difference at all (nothing more than the variance of my reaction times in start/stoping the stopwatch). So for my system, I haven't seen any objective evidence so far of preload's default settings speeding up the startup times of my apps (although I've only tested two apps).

Edit: I tested again on another app that I commonly use, a big one that takes a while to start up, and this time I did record a small difference (I did it more that once and took the average, rebooting before each one):
preload on: ave = 9.3s
preload off: ave = 10.7s
Maybe the difference stands out here because it takes a while to load as compared to the other two apps, but in saying that, the difference isn't great, and the difference disappears into the noise for smaller apps, at least on my system. So I'm wondering if it's worth running yet another daemon on my system since most apps I start only once a day.

[julian67]

There's another way to compare it which might be more convenient. I'm pretty sure this is a good method but if someone knows different please say.

With preload running and having had it running for some (weeks I guess):

reboot and log in

start several regularly used apps and record the start up times.

Next we clear the cached RAM

Code: Select all

# sync; echo 3 >> /proc/sys/vm/drop_caches

and again start several regularly used apps and record the start up times.

edit: I just tried this and found no real difference in application start times whereas when I wrote this howto the differences were large and unmistakeable. In the meantime I've moved from using i686 laptops to mostly using an amd64 desktop and I've also recompiled the kernel with the latest version from kernel.org and enabled preemption and changed the timer frequency to 1000 so I can't say which factor made the difference or if it's a combination though I suspect preemption is the key, but at the moment on my system I find application start up times are at least as good when preload is actually uninstalled so it's gone.

[Hadret]

noatime isn't needed in XFS, but is it recommended for ext4 (like it was for ext3)?

[julian67]

noatime isn't needed in XFS, but is it recommended for ext4 (like it was for ext3)?

From http://en.wikipedia.org/wiki/Ext4

Features
Dates recorded modification (mtime), attribute modification (ctime), access (atime), delete (dtime), create (crtime)

I haven't used ext4 but examples of people's fstab I've seen show noatime being used. If this is from necessity or habit I don't know. Suggest you read Ext4 overview

[Hadret]

julian67, I will, thank you! (:

[erykroom]

Thanks for the tips.

[jalu]

it wouldn`t hurt if that would be a sticky

(like you said: its about 10 minutes of work and, as far i can tell,
the system seems to be much more solid now
+ one is getting interested in the 'problem/topic'
+ its important for everyone).
thanks for that jalu

[Hadret]

What about Upstart? It's in Sid repository, does anybody use that? Is it fast? (:

[lbm]

Nice and usefull post. I have a couple of things to try thats for sure.

[hameau]

I have been a satisfied user of CONCURRENCY=shell since the end of last year, running Lenny (when it was testing) and subsequently Squeeze.

I'm pretty sure that it was recent updates to sysvinit (v2.86.ds1-63) that broke my system, boot stopping with a flashing cursor and no further action (further details below). Commenting the CONCURRENCY=shell line in /etc/default/rcS restored booting.

Interestingly, the difference between with and without CONCURRENCY=shell in the current Squeeze is almost too small to notice, though it certainly made a bigger difference when I first used it.

=====

For the sake of those Googling later, these were the significant lines from the boot process (not the full output):
getpt: no such file or directory
could not get pty for /etc/rcS.d/S02hostname.sh
could not get pty for /etc/rcS.d/S02mountkernfs.sh

The final line to appear before the boot process stopped indefinitely:
Waiting for /dev to be fully populated ... done
<flashing cursor>

[dbbolton]

I would like to mention, for those so inclined, that after installing insserv and setting the concurrency variable, I could not boot into my system. After removing the package and commenting out the concurrency line, I could once again boot: http://forums.debian.net/viewtopic.php? ... 53#p243853

Luckily this was on an experimental system. I know I would get to keep both pieces.