Difference between revisions of "Improve boot performance"

From ArchWiki
Jump to: navigation, search
(Comment out unused terminals: Clarify note, add internal link to SHA password hashes, clarify preceding text)
m (Corrected spelling)
(47 intermediate revisions by 18 users not shown)
Line 1: Line 1:
[[Category:Boot process (English)]]
+
[[Category:Boot process]]
{{i18n|Improve Boot Performance}}
+
[[cs:Improve Boot Performance]]
 
+
[[es:Improve Boot Performance]]
 +
[[ru:Improve Boot Performance]]
 +
[[zh-CN:Improve Boot Performance]]
 
{{Article summary start}}
 
{{Article summary start}}
{{Article summary text|This article attempts to aggregate methods on how to improve the boot performance of a system.}}
+
{{Article summary text|This article attempts to aggregate methods on how to improve the boot performance of an Arch Linux system.}}
 
{{Article summary end}}
 
{{Article summary end}}
  
==Preface==
+
Improving the boot performance of a system can provide reduced boot wait times and a means to learn more about how certain system files and scripts interact with one another. This article attempts to aggregate methods on how to improve the boot performance of an Arch Linux system.
Improving the boot performance of a system can provide reduced boot wait times and a means to learn more about how certain system files and scripts interact with one another. This article attempts to aggregate methods on how to improve the boot performance of a system.
+
  
==Modifying boot files==
+
== Identifying bottlenecks ==
===/etc/inittab===
+
  
====Asynchronous startup====
+
The {{ic|systemd-analyze}} command can be used to show timing details about the boot process, including an svg plot showing units waiting for their dependencies. See {{ic|man systemd-analyze}} for details.
{{Note|Using this means there are no guarantees that daemons are all started before X. This can cause problems if your setup expects dbus to be running (ck-launch-session, gnome, kde, etc.).}}
+
The initscripts can be started [[Wiktionary:asynchronous|asynchronously]] instead of running in a strict order.
+
  
<pre>
+
== Compiling a Custom Kernel ==
# use once instead of wait
+
rc::sysinit:/etc/rc.sysinit
+
rs:S1:wait:/etc/rc.single
+
rm:2345:once:/etc/rc.multi
+
rh:06:once:/etc/rc.shutdown
+
su:S:once:/sbin/sulogin -p
+
</pre>
+
  
====Comment out unused terminals====
+
To decrease boot time, a stripped kernel is a must.
 +
[[Kernel Compilation|Read more about compiling a kernel.]]
  
agetty terminals are console terminals brought up by <tt>Ctrl+Alt+F1-6</tt>.
+
== Early start for services ==
* Comment out unused terminals if only two terminals (<tt>tty1</tt> and <tt>tty2</tt> are required:
+
c1:2345:respawn:/sbin/agetty -8 38400 tty1 linux
+
c2:2345:respawn:/sbin/agetty -8 38400 tty2 linux
+
#c3:2345:respawn:/sbin/agetty -8 38400 tty3 linux
+
#c4:2345:respawn:/sbin/agetty -8 38400 tty4 linux
+
#c5:2345:respawn:/sbin/agetty -8 38400 tty5 linux
+
#c6:2345:respawn:/sbin/agetty -8 38400 tty6 linux
+
  
Additionally, consider using a lighter terminal manager such as {{Package Official|fgetty}}, which consists of the minimal tty manager, <tt>[http://aur.archlinux.org/packages.php?ID=13793 mingetty]</tt>, that has been stripped of printfs and compiled against {{Package Official|dietlibc}}.
+
One central feature of systemd is [[D-Bus]] and socket activation. This causes services to be started when they are first accessed and is generally a good thing. However, if you know that a service (like [[UPower]]) will always be started during boot, then the overall boot time might be reduced by starting it as early as possible. This can be achieved (if the service file is set up for it, which in most cases it is) by issuing:
  
{{Note|The very minimal terminal manager ''fgetty'' doesn't support sha512 password hashing by default. (see [[SHA password hashes]])}}
+
# systemctl enable upower
  
# pacman -S fgetty
+
This will cause systemd to start UPower as soon as possible, without causing races with the socket or D-Bus activation.
  
Change the following lines in {{Filename|/etc/inittab}} to reflect the use of <tt>fgetty</tt>:
+
==Staggered spin-up==
  
c1:2345:respawn:/sbin/fgetty tty1 linux
+
Some hardware implements [[Wikipedia:Spin-up#Staggered spin-up|staggered spin-up]], which causes the OS to probe ATA interfaces serially, which can spin up the drives one-by-one and reduce the peak power usage. This slows down the boot speed, and on most consumer hardware provides no benefits at all since the drives will already spin-up immediately when the power is turned on. To check if SSS is being used:
c2:2345:respawn:/sbin/fgetty tty2 linux
+
  
===/boot/grub/menu.lst===
+
  $ dmesg | grep SSS
This file lets you modify the kernel command line at boot. A couple ways to speed up boot time using this file to modify the kernel commandline is to remove framebuffer entries, and set the kernel loglevel to a lowlevel of logging with '''quiet'''.  For more kernel parameters and {{Filename|/boot/grub/menu.lst}} examples check out the archlinux page on [[GRUB]].  Remove existing <tt>vga=</tt> [[Wikipedia:Framebuffer|framebuffer]] resolution entries and '''logo.nologo''', parameters to the desired kernel:
+
kernel /vmlinuz26 root=/dev/disk/by-uuid/UUID ro logo.nologo quiet
+
  
===/etc/mkinitcpio.conf===
+
If it wasn't used during boot, there will be no output.
  
Delete the HOOKS you don't need, and consider using just base (sometimes udev is needed too) along with the MODULES you need for your root device (and keyboard, instead of usbinput).
+
To disable it, add {{ic|1=libahci.ignore_sss=1}} to the [[kernel line]].
  
Read more in the [[mkinitcpio|mkinitcpio article]].
+
==Filesystem Mounts==
  
===/etc/rc.conf===
+
Thanks to [[mkinitcpio]]'s {{ic|fsck}} hook, you can avoid a possibly costly remount of the root partition by changing {{ic|ro}} to {{ic|rw}} on the kernel line and removing it from {{ic|/etc/fstab}}. Options can be set with {{ic|1=rootflags=mount options...}} on the kernel line.
In the network section, make sure you only load the network interface you need. Manually configuring your network is also faster than using dhcp. Then find and remove all DAEMONS you don't need.
+
DAEMONS=(alsa network gdm)
+
  
Then move your Xdm to front, and background all DAEMONS.
+
You can also remove API filesystems from {{ic|/etc/fstab}}, as systemd will mount them itself (see {{ic|pacman -Ql systemd <nowiki>|</nowiki> grep '\.mount$'}} for a list). It is not uncommon for users to have a /tmp entry carried over from sysvinit, but you may have noticed from the command above that systemd already takes care of this.  Ergo, it may be safely removed.   
  DAEMONS=(@gdm @alsa @network)
+
  
Another thing you could do about daemons is finding the best, or rather, "sweetest" arrangement.
+
Other filesystems like {{ic|/home}} can be mounted with custom mount unitsAdding {{ic|noauto,x-systemd.automount}} will buffer all access to that partition, and will fsck and mount it on first access, reducing the number of filesystems it must fsck/mount during the boot process.
  DAEMONS=(syslog-ng @acpid arptables iptables network pdnsd @alsa @dbus @mpd @crond @sensors @ntpd @dropboxd)
+
  
You should try to background as many DAEMONS as possible, making sure to start dependent DAEMONS after what they require (in the above example, pdnsd depends on network, ntpd and dropboxd depend on pdnsd and network, because 127.0.0.1 is the dns server). You can still background daemons that are required by other things (dbus is required by the Xorg), but they need enough time to start (it can take some experimentation to get it all to work well).
+
==Initramfs==
  
=== /etc/rc.sysinit ===
+
As mentioned above, boot time can be decreased by slimming the kernel, thereby reducing the amount of data that must be loaded. This is also true for your initramfs (result of mkinitcpio), as this is loaded immediately after the kernel, and takes care of recognizing your root filesystem and mounting it. To boot, very little is actually needed and includes the storage bus, block device, and filesystem.  Falconindy (Dave Reisner) has begrudgingly created a [http://blog.falconindy.com/articles/optmizing-bootup-with-mkinitcpio.html short tutorial] on how to achieve this on his blog.
This script is responsible for the majority of output you see during boot, meaning this is a system-critical configuration file which looks up other files like ''rc.conf'' and loads modules, sets up mounts, handles errors, and basically tries to be your best friend.
+
  
There are certain lines here which you may not need. Removing or commenting them out may save you a few seconds at most. Do this at your own risk. For example, if you do not have RAID, LVM or encryption, then you would not need any lines concerning that.
+
== Less output during boot ==
  
It's also possible to add some ampersands (&) to make it more asynchronous, but be careful - lots of things are expected to be finished during later parts of the script.
+
Change {{ic|verbose}} to {{ic|quiet}} on the bootloader's kernel line. For some systems, particularly those with an SSD, the slow performance of the TTY is actually a bottleneck, and so less output means faster booting.
 
+
== Compiling a Custom Kernel ==
+
 
+
To decrease boot time, a stripped kernel is a must.
+
[[Kernel_Compilation_From_Source | Read more about compiling a kernel. ]]
+
  
 
== Additional Resources ==
 
== Additional Resources ==
* [[Arch Boot Process]]
+
* [[systemd]]
 +
* [[e4rat]]
 
* [[udev]]
 
* [[udev]]
* [[Daemons]]
+
* [[Daemon]]
* [[rc.conf]]
+
 
* [[mkinitcpio]]
 
* [[mkinitcpio]]
 
* [[Maximizing Performance]]
 
* [[Maximizing Performance]]
* [[Systemd]]
+
* [[Bootchart]] - A tool to assist in profiling the boot process
 +
* [[Kexec]] A tool to reboot very quickly without waiting for the whole BIOS boot process to finish.

Revision as of 13:06, 22 November 2012

Summary help replacing me
This article attempts to aggregate methods on how to improve the boot performance of an Arch Linux system.

Improving the boot performance of a system can provide reduced boot wait times and a means to learn more about how certain system files and scripts interact with one another. This article attempts to aggregate methods on how to improve the boot performance of an Arch Linux system.

Identifying bottlenecks

The systemd-analyze command can be used to show timing details about the boot process, including an svg plot showing units waiting for their dependencies. See man systemd-analyze for details.

Compiling a Custom Kernel

To decrease boot time, a stripped kernel is a must. Read more about compiling a kernel.

Early start for services

One central feature of systemd is D-Bus and socket activation. This causes services to be started when they are first accessed and is generally a good thing. However, if you know that a service (like UPower) will always be started during boot, then the overall boot time might be reduced by starting it as early as possible. This can be achieved (if the service file is set up for it, which in most cases it is) by issuing:

# systemctl enable upower

This will cause systemd to start UPower as soon as possible, without causing races with the socket or D-Bus activation.

Staggered spin-up

Some hardware implements staggered spin-up, which causes the OS to probe ATA interfaces serially, which can spin up the drives one-by-one and reduce the peak power usage. This slows down the boot speed, and on most consumer hardware provides no benefits at all since the drives will already spin-up immediately when the power is turned on. To check if SSS is being used:

$ dmesg | grep SSS

If it wasn't used during boot, there will be no output.

To disable it, add libahci.ignore_sss=1 to the kernel line.

Filesystem Mounts

Thanks to mkinitcpio's fsck hook, you can avoid a possibly costly remount of the root partition by changing ro to rw on the kernel line and removing it from /etc/fstab. Options can be set with rootflags=mount options... on the kernel line.

You can also remove API filesystems from /etc/fstab, as systemd will mount them itself (see pacman -Ql systemd | grep '\.mount$' for a list). It is not uncommon for users to have a /tmp entry carried over from sysvinit, but you may have noticed from the command above that systemd already takes care of this. Ergo, it may be safely removed.

Other filesystems like /home can be mounted with custom mount units. Adding noauto,x-systemd.automount will buffer all access to that partition, and will fsck and mount it on first access, reducing the number of filesystems it must fsck/mount during the boot process.

Initramfs

As mentioned above, boot time can be decreased by slimming the kernel, thereby reducing the amount of data that must be loaded. This is also true for your initramfs (result of mkinitcpio), as this is loaded immediately after the kernel, and takes care of recognizing your root filesystem and mounting it. To boot, very little is actually needed and includes the storage bus, block device, and filesystem. Falconindy (Dave Reisner) has begrudgingly created a short tutorial on how to achieve this on his blog.

Less output during boot

Change verbose to quiet on the bootloader's kernel line. For some systems, particularly those with an SSD, the slow performance of the TTY is actually a bottleneck, and so less output means faster booting.

Additional Resources