Difference between revisions of "Improving performance/Boot process"

From ArchWiki
Jump to: navigation, search
(Initramfs - udev note)
(32 intermediate revisions by 9 users not shown)
Line 1: Line 1:
 
[[Category:Boot process]]
 
[[Category:Boot process]]
 +
[[ar:Improve Boot Performance]]
 
[[cs:Improve Boot Performance]]
 
[[cs:Improve Boot Performance]]
 
[[es:Improve Boot Performance]]
 
[[es:Improve Boot Performance]]
Line 7: Line 8:
 
{{Article summary text|This article attempts to aggregate methods on how to improve the boot performance of an Arch Linux 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}}
{{out of date|systemd and grub2}}
 
  
==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 an Arch Linux system.
  
==Modifying boot files==
+
== Analyzing the boot process ==
===/etc/inittab===
+
  
====Asynchronous startup====
+
=== Using systemd-analyze ===
{{Note|Using this means there are no guarantees that daemons are all started before [[Xorg|X]]. This can cause problems if your setup expects [[D-Bus]] to be running (ck-launch-session, [[GNOME]], [[KDE]], etc.).}}
+
The initscripts can be started [[Wiktionary:asynchronous|asynchronously]] instead of running in a strict order.
+
  
# use once instead of wait
+
The {{ic|systemd-analyze}} command
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
+
  
====TTY terminal management====
+
'''systemd''' provides a tool called {{ic|systemd-analyze}} that can be used to show timing details about the boot process, including an svg plot showing units waiting for their dependencies. You can see which unit files are causing your boot process to slow down. You can then optimize your system accordingly.
  
''agetty'' is Arch Linux's default terminal manager. By default it will generate six terminals, which can be accessed by typing {{Keypress|Ctrl+Alt+F[1-6]}}. To increase performance you can comment out unused terminals.
+
To see how much time was spent in kernelspace and userspace on boot, simply use:
{{hc|/etc/inittab|<nowiki>
+
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
+
</nowiki>}}
+
  
Additionally, consider using a lighter terminal manager such as {{AUR|fgetty}}, which consists of the minimal tty manager, {{Pkg|mingetty}}, that has been stripped of printfs and compiled against {{Pkg|dietlibc}}.
+
$ systemd-analyze
  
{{Note|{{AUR|fgetty}} currently does not support SHA-512 password hashing by default; a patched {{AUR|fgetty-pam}} is available in the [[Arch User Repository|AUR]]. See [[SHA password hashes]] for more information.}}
+
{{Tip|
 +
* If you append the {{ic|timestamp}} hook to your {{ic|HOOKS}} array in {{ic|/etc/[[mkinitcpio]].conf}} and rebuild your initramfs with {{ic|mkinitcpio -p linux}}, '''systemd-analyze''' is also able to show you how much time was spent in the initramfs.
 +
* If you boot via [[UEFI]] and use a boot loader which implements systemds' [http://www.freedesktop.org/wiki/Software/systemd/BootLoaderInterface Boot Loader Interface] (which currently only [[Gummiboot]] does), '''systemd-analyze''' can additionally show you how much time was spent in the EFI firmware and the boot loader itself.}}
  
You can [[AUR_Helpers|install]] {{AUR|fgetty}} from the [[Arch User Repository|AUR]].
+
To list the started unit files, sorted by the time each of them took to start up:
  
Then replace {{ic|agetty}} with {{ic|fgetty}} on the following lines:
+
  $ systemd-analyze blame
{{hc|/etc/inittab|<nowiki>
+
  c1:2345:respawn:/sbin/fgetty tty1 linux
+
c2:2345:respawn:/sbin/fgetty tty2 linux
+
</nowiki>}}
+
  
===/boot/grub/grub.cfg===
+
At some points of the boot process, things can not proceed until a given unit succeeds. To see which units find themselves at these critical points in the startup chain, do:
This file lets you modify the kernel command line at boot. A couple of ways to speed up boot time using this file to modify the kernel command line is to remove framebuffer entries and to set the kernel to use a low level of logging with {{ic|quiet}}. Remove existing {{ic|1=vga=}} [[Wikipedia:Framebuffer|framebuffer]] resolution entries and {{ic|logo.nologo}}, parameters to the desired kernel:
+
  
  linux /vmlinuz-linux root=/dev/disk/by-uuid/UUID ro logo.nologo quiet
+
  $ systemd-analyze critical-chain
  
For more kernel parameters and {{ic|/boot/grub/menu.lst}} examples check out the page on [[Boot Debugging]] using [[GRUB]].
+
You can also create a SVG file which describes your boot process graphically, similiar to [[Bootchart]]:
  
===/etc/mkinitcpio.conf===
+
$ systemd-analyze plot > plot.svg
  
Delete the HOOKS you do not need, and consider using just base (sometimes [[udev]] is needed too) along with the [[Kernel modules|MODULES]] you need for your root device (and keyboard, instead of usbinput).
+
See {{ic|man systemd-analyze}} for details.
  
{{Warning|Read more about what hooks are required in the [[mkinitcpio]] article. Removing required hooks can render your system unusable!}}
+
=== Using systemd-bootchart ===
  
===/etc/rc.conf===
+
Bootchart has been merged into '''systemd''' since Oct. 17, and you can use it to boot just as you would with the original bootchart. Add this to your kernel line:
In the network section, make sure you only load the network interface you need. Manually configuring your network with a static IP address is also faster than using DHCP.
+
  
Then find and remove all DAEMONS that you do not need.
+
  initcall_debug printk.time=y init=/usr/lib/systemd/systemd-bootchart
  DAEMONS=(alsa network gdm)
+
  
Next, move your login manager (in this case {{Pkg|gdm}}) to the front, and background all DAEMONS.
+
=== Using bootchart2 ===
DAEMONS=(@gdm @alsa @network)
+
  
Another thing you could do about daemons is finding the best, or rather, "sweetest" arrangement.
+
You could also use a version of bootchart to visualize the boot sequence. Since you are not able to put a second init into the kernel command line you won't be able to use any of the standard bootchart setups. However the {{AUR|bootchart2-git}} package from [[AUR]] comes with an undocumented '''systemd''' service. After you've installed bootchart2 do:
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, {{ic|pdnsd}} depends on {{ic|network}}, {{ic|ntpd}} and {{ic|dropboxd}} depend on {{ic|pdnsd}} and {{ic|network}}, because 127.0.0.1 is the DNS server). You can still background daemons that are required by other things ({{ic|dbus}} is required by [[Xorg]]), but they need enough time to start (it can take some experimentation to get it all to work well).
+
# systemctl enable bootchart
  
=== /etc/rc.sysinit ===
+
Read the [https://github.com/mmeeks/bootchart bootchart documentation] for further details on using this version of bootchart.
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 {{ic|/etc/[[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.
+
== Readahead ==
  
It is also possible to add some ampersands ({{ic|&}}) to make it more asynchronous, but be careful - lots of things are expected to be finished during later parts of the script.
+
[[Systemd]] comes with its own readahead implementation, this should in principle improve boot time. However, depending on your kernel version and the type of your hard drive, your mileage may vary (i.e. it might be slower). To enable, do:
 +
 
 +
# systemctl enable systemd-readahead-collect systemd-readahead-replay
 +
 
 +
Remember that in order for the readahead to work its magic, you should reboot a couple of times.
  
 
== Compiling a Custom Kernel ==
 
== Compiling a Custom Kernel ==
  
To decrease boot time, a stripped kernel is a must.
+
Compiling a custom kernel can reduce boot time and memory usage. Though with the standardization of the 64 bit architecture and the modular nature of the Linux kernel, these benefits may not be as great as expected. [[Kernel Compilation|Read more about compiling a kernel.]]
[[Kernel Compilation|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 [[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:
 +
 
 +
$ dmesg | grep SSS
 +
 
 +
If it wasn't used during boot, there will be no output.
 +
 
 +
To disable it, add {{ic|1=libahci.ignore_sss=1}} to the [[kernel line]].
 +
 
 +
==Filesystem Mounts==
 +
 
 +
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. Remember to remove the entry from your /etc/fstab file, else the systemd-remount-fs.service will continue to try to apply those settings.  Alternatively, one could try to mask that unit.
 +
 
 +
If btrfs is in use for the root filesystem, there is no need for a fsck on every boot like other filesystems.  If this is the case, [[mkinitcpio]]'s {{ic|fsck}} hook can be removed.  You may also want to mask the {{ic|systemd-fsck-root.service}}, or tell it not to fsck the root filesystem from the kernel command line using {{ic|fsck.mode&#61;skip}}.  Without [[mkinitcpio]]'s {{ic|fsck}} hook, systemd will still fsck any relevant filesystems with the {{ic|systemd-fsck@.service}}
 +
 
 +
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.
 +
 
 +
Other filesystems like {{ic|/home}} can be mounted with custom mount units.  Adding {{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.
 +
 
 +
{{Note|this will make your {{ic|/home}} filesystem type {{ic|autofs}}, which is ignored by [[mlocate]] by default. The speedup of automounting {{ic|/home}} may not be more than a second or two, depending on your system, so this trick may not be worth it.}}
 +
 
 +
==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 [http://blog.falconindy.com/articles/optmizing-bootup-with-mkinitcpio.html short tutorial] on how to achieve this on his blog.
 +
{{Note|If you are using anything that requires udev to be included in the initramfs (for example, lvm2, mdadm_udev, or even just specifying the filesystem label with /dev/disk/by-label), trying to strip down your initramfs will not be a worthwhile endeavor.}}
 +
 
 +
== Less output during boot ==
 +
 
 +
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.
  
 
== Additional Resources ==
 
== Additional Resources ==
* [[Arch Boot Process]]
+
* [[systemd]]
 
* [[e4rat]]
 
* [[e4rat]]
 
* [[udev]]
 
* [[udev]]
 
* [[Daemon]]
 
* [[Daemon]]
* [[rc.conf]]
 
 
* [[mkinitcpio]]
 
* [[mkinitcpio]]
 
* [[Maximizing Performance]]
 
* [[Maximizing Performance]]
* [[Systemd]] - An alternative init process
 
 
* [[Bootchart]] - A tool to assist in profiling the boot process
 
* [[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.
 
* [[Kexec]] A tool to reboot very quickly without waiting for the whole BIOS boot process to finish.

Revision as of 14:08, 22 July 2013

Template:Article summary start Template:Article summary text Template:Article summary end

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.

Analyzing the boot process

Using systemd-analyze

The systemd-analyze command

systemd provides a tool called systemd-analyze that can be used to show timing details about the boot process, including an svg plot showing units waiting for their dependencies. You can see which unit files are causing your boot process to slow down. You can then optimize your system accordingly.

To see how much time was spent in kernelspace and userspace on boot, simply use:

$ systemd-analyze
Tip:
  • If you append the timestamp hook to your HOOKS array in /etc/mkinitcpio.conf and rebuild your initramfs with mkinitcpio -p linux, systemd-analyze is also able to show you how much time was spent in the initramfs.
  • If you boot via UEFI and use a boot loader which implements systemds' Boot Loader Interface (which currently only Gummiboot does), systemd-analyze can additionally show you how much time was spent in the EFI firmware and the boot loader itself.

To list the started unit files, sorted by the time each of them took to start up:

$ systemd-analyze blame

At some points of the boot process, things can not proceed until a given unit succeeds. To see which units find themselves at these critical points in the startup chain, do:

$ systemd-analyze critical-chain

You can also create a SVG file which describes your boot process graphically, similiar to Bootchart:

$ systemd-analyze plot > plot.svg

See man systemd-analyze for details.

Using systemd-bootchart

Bootchart has been merged into systemd since Oct. 17, and you can use it to boot just as you would with the original bootchart. Add this to your kernel line:

initcall_debug printk.time=y init=/usr/lib/systemd/systemd-bootchart

Using bootchart2

You could also use a version of bootchart to visualize the boot sequence. Since you are not able to put a second init into the kernel command line you won't be able to use any of the standard bootchart setups. However the bootchart2-gitAUR package from AUR comes with an undocumented systemd service. After you've installed bootchart2 do:

# systemctl enable bootchart

Read the bootchart documentation for further details on using this version of bootchart.

Readahead

Systemd comes with its own readahead implementation, this should in principle improve boot time. However, depending on your kernel version and the type of your hard drive, your mileage may vary (i.e. it might be slower). To enable, do:

# systemctl enable systemd-readahead-collect systemd-readahead-replay

Remember that in order for the readahead to work its magic, you should reboot a couple of times.

Compiling a Custom Kernel

Compiling a custom kernel can reduce boot time and memory usage. Though with the standardization of the 64 bit architecture and the modular nature of the Linux kernel, these benefits may not be as great as expected. 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. Remember to remove the entry from your /etc/fstab file, else the systemd-remount-fs.service will continue to try to apply those settings. Alternatively, one could try to mask that unit.

If btrfs is in use for the root filesystem, there is no need for a fsck on every boot like other filesystems. If this is the case, mkinitcpio's fsck hook can be removed. You may also want to mask the systemd-fsck-root.service, or tell it not to fsck the root filesystem from the kernel command line using fsck.mode=skip. Without mkinitcpio's fsck hook, systemd will still fsck any relevant filesystems with the systemd-fsck@.service

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.

Note: this will make your /home filesystem type autofs, which is ignored by mlocate by default. The speedup of automounting /home may not be more than a second or two, depending on your system, so this trick may not be worth it.

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.

Note: If you are using anything that requires udev to be included in the initramfs (for example, lvm2, mdadm_udev, or even just specifying the filesystem label with /dev/disk/by-label), trying to strip down your initramfs will not be a worthwhile endeavor.

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