Difference between revisions of "Improving performance/Boot process"
m (→Compiling a Custom Kernel: Update words.) |
Lahwaacz.bot (talk | contribs) (simplification and beautification of wikilinks (interactive)) (Tag: wiki-scripts) |
||
(75 intermediate revisions by 32 users not shown) | |||
Line 1: | Line 1: | ||
[[Category:Boot process]] | [[Category:Boot process]] | ||
− | [[cs:Improve | + | [[ar:Improve boot performance]] |
− | [[es:Improve | + | [[cs:Improve boot performance]] |
− | [[ru: | + | [[es:Improve boot performance]] |
− | [[zh- | + | [[it:Improve boot performance]] |
− | {{ | + | [[ja:ブートパフォーマンスの向上]] |
− | {{ | + | [[ru:Improving performance/Boot process]] |
− | {{ | + | [[zh-hans:Improve boot performance]] |
+ | {{Related articles start}} | ||
+ | {{Related|Improving performance}} | ||
+ | {{Related|Silent boot}} | ||
+ | {{Related|Daemon}} | ||
+ | {{Related|e4rat}} | ||
+ | {{Related|Kexec}} | ||
+ | {{Related articles 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. | 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 === | |
− | + | [[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. | |
− | Compiling a custom kernel | + | To see how much time was spent in kernelspace and userspace on boot, simply use: |
+ | |||
+ | $ systemd-analyze | ||
+ | |||
+ | {{Tip|If you boot via [[UEFI]] and use a boot loader which implements systemd's [http://www.freedesktop.org/wiki/Software/systemd/BootLoaderInterface Boot Loader Interface] (which currently [[systemd-boot]] and [[GRUB]] do), ''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 an SVG file which describes your boot process graphically, similiar to [[Bootchart]]: | ||
+ | |||
+ | $ systemd-analyze plot > plot.svg | ||
+ | |||
+ | See {{man|1|systemd-analyze}} for details. | ||
+ | |||
+ | === Using systemd-bootchart === | ||
+ | |||
+ | Bootchart is part of ''systemd'' and can be used at boot time passing the following option to the kernel command line: {{ic|1=initcall_debug printk.time=y init=/usr/lib/systemd/systemd-bootchart}}. | ||
+ | |||
+ | After collecting a certain amount of data (configurable) the logging stops and a graph is generated from the logged information. This graph contains vital clues as to which resources are being used (by default I/O, CPU utilization and kernel init threads), in which order, and where possible problems exist in the startup sequence of the system. It is essentially a more detailed version of the systemd-analyze plot function. | ||
+ | |||
+ | Bootchart graphs are by default written time-stamped in {{ic|/run/log}} and saved to the journal with | ||
+ | ''MESSAGE_ID=9f26aa562cf440c2b16c773d0479b518''. Journal field ''BOOTCHART='' contains the bootchart in SVG format. | ||
+ | See the [http://www.freedesktop.org/software/systemd/man/systemd-bootchart.html manpage] for more information. | ||
+ | |||
+ | === Using bootchart2 === | ||
+ | |||
+ | {{Merge|Bootchart#Running Bootchart2|different instructions from the main page}} | ||
+ | |||
+ | 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: | ||
+ | |||
+ | # systemctl enable bootchart2 | ||
+ | |||
+ | You can visualize the results by opening ''/var/log/bootchart.png'', or if you would like more features by launching | ||
+ | |||
+ | $ pybootchartgui -i | ||
+ | |||
+ | Read the [https://github.com/mmeeks/bootchart bootchart2 documentation] for further details on using this version of bootchart. | ||
+ | |||
+ | == 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. [[Kernel Compilation|Read more about compiling a kernel]]. | ||
+ | |||
+ | == Initramfs == | ||
+ | |||
+ | In a similar approach to [[#Compiling a custom kernel]], the initramfs can be slimmed down. A simple way is to include the [[mkinitcpio]] {{ic|autodetect}} hook. If you want to go further than that, see [[Minimal initramfs]]. | ||
== Early start for services == | == Early start for services == | ||
Line 26: | Line 83: | ||
This will cause systemd to start UPower as soon as possible, without causing races with the socket or D-Bus activation. | This will cause systemd to start UPower as soon as possible, without causing races with the socket or D-Bus activation. | ||
− | ==Staggered spin-up== | + | == 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: | 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: | ||
Line 34: | Line 91: | ||
If it wasn't used during boot, there will be no output. | If it wasn't used during boot, there will be no output. | ||
− | To disable it, add {{ic|1=libahci.ignore_sss=1}} | + | To disable it, add {{ic|1=libahci.ignore_sss=1}} [[kernel parameter]]. |
− | ==Filesystem | + | == 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 | + | 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: options can be set with {{ic|1=rootflags='''rw''',''other_mount_options''}}. The entry must be removed from the {{ic|/etc/fstab}} file, otherwise the {{ic|systemd-remount-fs.service}} will continue to try applying these 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=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}} or [[EFI System Partition]] can be mounted with custom mount units. Adding {{ic|noauto,x-systemd.automount}} to mount options 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. | ||
+ | * If the system is installed into a ''btrfs'' subvolume (specifically: the root directory {{ic|/}} itself is a subvolume) and {{ic|/home}} is a separate file system, you may also want to prevent the creation of a {{ic|/home}} subvolume. Mask the {{ic|home.conf}} tmpfile: {{ic|ln -s /dev/null /etc/tmpfiles.d/home.conf}}. | ||
+ | }} | ||
− | + | == Less output during boot == | |
− | + | 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. See the [[Silent boot]] article for suggestions. | |
− | + | == Suspend to RAM == | |
− | + | The best way to reduce boot time is not booting at all. Consider [[Power management/Suspend and hibernate|suspending your system to RAM]] instead. | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− |
Latest revision as of 22:33, 7 February 2018
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.
Contents
Analyzing the boot process
Using systemd-analyze
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
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 an SVG file which describes your boot process graphically, similiar to Bootchart:
$ systemd-analyze plot > plot.svg
See systemd-analyze(1) for details.
Using systemd-bootchart
Bootchart is part of systemd and can be used at boot time passing the following option to the kernel command line: initcall_debug printk.time=y init=/usr/lib/systemd/systemd-bootchart
.
After collecting a certain amount of data (configurable) the logging stops and a graph is generated from the logged information. This graph contains vital clues as to which resources are being used (by default I/O, CPU utilization and kernel init threads), in which order, and where possible problems exist in the startup sequence of the system. It is essentially a more detailed version of the systemd-analyze plot function.
Bootchart graphs are by default written time-stamped in /run/log
and saved to the journal with
MESSAGE_ID=9f26aa562cf440c2b16c773d0479b518. Journal field BOOTCHART= contains the bootchart in SVG format.
See the manpage for more information.
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 bootchart2
You can visualize the results by opening /var/log/bootchart.png, or if you would like more features by launching
$ pybootchartgui -i
Read the bootchart2 documentation for further details on using this version of bootchart.
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.
Initramfs
In a similar approach to #Compiling a custom kernel, the initramfs can be slimmed down. A simple way is to include the mkinitcpio autodetect
hook. If you want to go further than that, see Minimal initramfs.
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
kernel parameter.
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: options can be set with rootflags=rw,other_mount_options
. The entry must be removed from the /etc/fstab
file, otherwise the systemd-remount-fs.service
will continue to try applying these 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
or EFI System Partition can be mounted with custom mount units. Adding noauto,x-systemd.automount
to mount options 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.
- This will make your
/home
filesystem typeautofs
, 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. - If the system is installed into a btrfs subvolume (specifically: the root directory
/
itself is a subvolume) and/home
is a separate file system, you may also want to prevent the creation of a/home
subvolume. Mask thehome.conf
tmpfile:ln -s /dev/null /etc/tmpfiles.d/home.conf
.
Less output during boot
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. See the Silent boot article for suggestions.
Suspend to RAM
The best way to reduce boot time is not booting at all. Consider suspending your system to RAM instead.