Analyze Linux Boot Performance
Are you using systemd system and service manager, and your Linux system taking longer time to boot or you simple want to view the reports of your system boot-up performance? If yes, you have landed on the right place.
In this article, we will show you how to analyze a Linux system boot-up performance statistics using systemd-analyze, one of numerous utilities under systemd for system management.
Read Also: How to Control Systemd Services on Remote Linux Server
To get an overview of the system boot-up time, we can run systemd-analyze command without any arguments as follows. It will list information about how much time each service took to start, which includes time taken by kernel, initrd and userspace while booting.
# systemd-analyze Startup finished in 884ms (kernel) + 3.861s (initrd) + 48.356s (userspace) = 53.102sIf you want to view a list of all running units, sorted by the time they took to initialize (highest time on top), the blame sub-command is used for this purpose. After running the command that follows, use [Enter] to view more services in the list and q to quit.
# systemd-analyze blameFind Out Time Each Unit Took to Start
16.159s mariadb.service 12.178s libvirtd.service 10.298s tuned.service 9.836s postfix.service 8.704s lsws.service 7.352s lscpd.service 4.988s 4.779s NetworkManager-wait-online.service 4.577s lvm2-monitor.service 4.439s ModemManager.service 4.413s polkit.service 4.280s dev-sda1.device 4.225s systemd-udev-settle.service 3.957s firewalld.service 3.227s rhel-dmesg.service 3.221s abrt-ccpp.service 3.142s rsyslog.service 3.053s avahi-daemon.service 3.042s pure-ftpd.service 2.249s gssproxy.service 2.212s NetworkManager.service 1.889s proc-fs-nfsd.mount 1.780s systemd-tmpfiles-setup-dev.service 1.451s sshd.service 1.267s rhel-readonly.service 1.035s sysstat.service 1.001s rpc-statd-notify.service 910ms systemd-logind.service 739ms kdump.service 738ms network.service ...As you can see from the above output that each unit is sorted based on the time taken, you can simply find out which service is taking longer time while booting and analyze the issue.
Next, we can also view a tree of the time-critical chain for the default target or a list of specified units with the critical-chain sub-command as shown.
# systemd-analyze critical-chainPrint time-critical Chain for Default Target
The time after the unit is active or started is printed after the "@" character. The time the unit takes to start is printed after the "+" character. multi-user.target @48.342s └─mariadb.service @31.560s +16.159s └─network.target @31.558s └─network.service @30.819s +738ms └─NetworkManager-wait-online.service @26.035s +4.779s └─NetworkManager.service @23.821s +2.212s └─network-pre.target @23.821s └─firewalld.service @19.863s +3.957s └─polkit.service @15.381s +4.413s └─basic.target @12.271s └─sockets.target @12.271s └─virtlockd.socket @12.270s └─sysinit.target @12.251s └─systemd-update-utmp.service @12.196s +54ms └─auditd.service @11.705s +486ms └─systemd-tmpfiles-setup.service @11.609s +93ms └─rhel-import-state.service @11.397s +211ms └─local-fs.target @11.363s └─run-user-0.mount @46.910s └─local-fs-pre.target @10.575s └─lvm2-monitor.service @5.996s +4.577s └─lvm2-lvmetad.service @7.376s └─lvm2-lvmetad.socket @5.987s └─-.slice # systemd-analyze critical-chain ntp.service networking.serviceFinally, let’s look at one more important sub-command that allows for producing graphical (svg format) detailing of system services that have been started, and at what time, highlighting their initialization time, as follows.
Make sure graphical display mode or x-windows is enabled in order to view the plot.
# systemd-analyze plot > boot_analysis.svg # xviewer boot_analysis.svgAll the above commands will print the boot-up performance statistics for the local machine. To view information from a remote host over ssh, use the -H flag and specify the username@host directive, as shown.
# systemd-analyze time -H # systemd-analyze blame -H # systemd-analyze critical-chain -Hsystemd-analyze can also be used to find other state and tracing information from the system and systemd (service manager) and more. For more information, see its man page.
# man systemd-analyzeRead Also: How to Change Runlevels (targets) in SystemD
That’s it for now! If you have any questions or thought to share, use the feedback form below to reach us.
The systemd-analyze command's time, blame, etc. options can be used to determine the "system boot performance" by outputting some timing information about its current boot. Is there a method to get the same information for the system's previous boots?
2
There is a list of systemd unit files that are enabled by default. System services that are defined by these unit files are automatically run at boot, which influences the boot time. This section describes:
To examine system boot performance, you can use the systemd-analyze command. This command has many options available. However, this section covers only the selected ones that may be important for systemd tuning in order to shorten the boot time.
For a complete list and detailed description of all options, see the systemd-analyze man page.
Prerequisites
- Before starting to examine systemd in order to tune the boot time, you may want to list all enabled services:
Procedure
$ systemctl list-unit-files --state=enabled
Analyzing overall boot time
Procedure
- For the overall information about the time that the last successful boot took, use:
Analyzing unit initialization time
Procedure
- For the information about the initialization time of each systemd unit, use:
The output lists the units in descending order according to the time they took to initialize during the last successful boot.
Identifying critical units
Procedure
- To identify the units that took most time to initialize at the last successful boot, use:
The output highlights the units that critically slow down the boot with the red color.
Figure 18.1. The output of the systemd-analyze critical-chain command
If you find the boot time of your system long, you can shorten it by disabling some of the services enabled on boot by default.
To list such services, run:
$ systemctl list-unit-files --state=enabledTo disable a service, run:
# systemctl disable service_nameHowever, certain services must stay enabled in order that your operating system is safe and functions in the way you need.
You can use the table below as a guide to selecting the services that you can safely disable. The table lists all services enabled by default on a minimal installation of Red Hat Enterprise Linux, and for each service it states whether this service can be safely disabled.
The table also provides more information about the circumstances under which the service can be disabled, or the reason why you should not disable the service.
Table 18.1. Services enabled by default on a minimal installation of RHEL
| auditd.service | yes | Disable auditd.service only if you do not need audit messages from the kernel. Be aware that if you disable auditd.service, the /var/log/audit/audit.log file is not produced. Consequently, you are not able to retroactively review some commonly-reviewed actions or events, such as user logins, service starts or password changes. Also note that auditd has two parts: a kernel part, and a service itself. By using the systemctl disable auditd command, you only disable the service, but not the kernel part. To disable system auditing in its entirety, set audit=0 on kernel command line. |
| autovt@.service | no | This service runs only when it is really needed, so it does not need to be disabled. |
| crond.service | yes | Be aware that no items from crontab will run if you disable crond.service. |
| dbus-org.fedoraproject.FirewallD1.service | yes | A symlink to firewalld.service |
| dbus-org.freedesktop.NetworkManager.service | yes | A symlink to NetworkManager.service |
| dbus-org.freedesktop.nm-dispatcher.service | yes | A symlink to NetworkManager-dispatcher.service |
| firewalld.service | yes | Disable firewalld.service only if you do not need firewall. |
| getty@.service | no | This service runs only when it is really needed, so it does not need to be disabled. |
| import-state.service | yes | Disable import-state.service only if you do not need to boot from a network storage. |
| irqbalance.service | yes | Disable irqbalance.service only if you have just one CPU. Do not disable irqbalance.service on systems with multiple CPUs. |
| kdump.service | yes | Disable kdump.service only if you do not need reports from kernel crashes. |
| loadmodules.service | yes | This service is not started unless the /etc/rc.modules or /etc/sysconfig/modules directory exists, which means that it is not started on a minimal RHEL installation. |
| lvm2-monitor.service | yes | Disable lvm2-monitor.service only if you do not use Logical Volume Manager (LVM). |
| microcode.service | no | Do not be disable the service because it provides updates of the microcode software in CPU. |
| NetworkManager-dispatcher.service | yes | Disable NetworkManager-dispatcher.service only if you do not need notifications on network configuration changes (for example in static networks). |
| NetworkManager-wait-online.service | yes | Disable NetworkManager-wait-online.service only if you do not need working network connection available right after the boot. If the service is enabled, the system does not finish the boot before the network connection is working. This may prolong the boot time significantly. |
| NetworkManager.service | yes | Disable NetworkManager.service only if you do not need connection to a network. |
| nis-domainname.service | yes | Disable nis-domainname.service only if you do not use Network Information Service (NIS). |
| rhsmcertd.service | no | |
| rngd.service | yes | Disable rngd.service only if you do not need a lot of entropy on your system, or you do not have any sort of hardware generator. Note that the service is necessary in environments that require a lot of good entropy, such as systems used for generation of X.509 certificates (for example the FreeIPA server). |
| rsyslog.service | yes | Disable rsyslog.service only if you do not need persistent logs, or you set systemd-journald to persistent mode. |
| selinux-autorelabel-mark.service | yes | Disable selinux-autorelabel-mark.service only if you do not use SELinux. |
| sshd.service | yes | Disable sshd.service only if you do not need remote logins by OpenSSH server. |
| sssd.service | yes | Disable sssd.service only if there are no users who log in the system over the network (for example by using LDAP or Kerberos). Red Hat recommends to disable all sssd-* units if you disable sssd.service. |
| syslog.service | yes | An alias for rsyslog.service |
| tuned.service | yes | Disable tuned.service only if you do need to use performance tuning. |
| lvm2-lvmpolld.socket | yes | Disable lvm2-lvmpolld.socket only if you do not use Logical Volume Manager (LVM). |
| dnf-makecache.timer | yes | Disable dnf-makecache.timer only if you do not need your package metadata to be updated automatically. |
| unbound-anchor.timer | yes | Disable unbound-anchor.timer only if you do not need daily update of the root trust anchor for DNS Security Extensions (DNSSEC). This root trust anchor is used by Unbound resolver and resolver library for DNSSEC validation. |
To find more information about a service, you can run one of the following commands:
$ systemctl cat <service_name>$ systemctl help <service_name>The systemctl cat command provides the content of the service file located under /usr/lib/systemd/system/<service>, as well as all applicable overrides. The applicable overrides include unit file overrides from the /etc/systemd/system/<service> file or drop-in files from a corresponding unit.type.d directory.
For more information on drop-in files, see the systemd.unit man page.
The systemctl help command shows the man page of the particular service.
- systemctl(1) man page
- systemd(1) man page
- systemd-delta(1) man page
- systemd.directives(7) man page
- systemd.unit(5) man page
- systemd.service(5) man page
- systemd.target(5) man page
- systemd.kill(5) man page
- systemd Home Page