Analysing performance problems with systemd
Now that Systemd is the default init-system in fresh installations of Debian GNU/Linux it is worth highlighting some of the new features.
One thing that Systemd is designed to do is speed up the booting of systems. True most installations are "servers" and as-such they're rarely rebooted, but I've been living with and working with a Debian laptop and Debian desktop for the past few years – and the laptop gets shutdown every day, and for that reason it is interesting to see how long a boot takes, and where that time is taken.
Three interesting commands to look at the boot-speed of a system are:
- systemd-analyze
- systemd-analyze critical-chain
- systemd-analyze blame
This allow you to see the times that are taken to start various things. For example the second command on this laptop shows me:
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. graphical.target @5.384s └─multi-user.target @5.384s └─NetworkManager.service @5.105s +278ms └─basic.target @5.103s └─paths.target @5.103s └─acpid.path @5.103s └─sysinit.target @5.102s └─console-setup.service @5.047s +54ms └─kbd.service @5.024s +23ms └─remote-fs.target @5.023s └─local-fs.target @5.022s └─lvm2-monitor.service @4.995s +24ms └─system.slice @70ms └─-.slice @68ms
Similarly if I run the "systemd-analyze blame" command I can see that the longest stall is waiting for:
4.548s [email protected]
Most of this stall is waiting for me to enter the passphrase for my encrypted /home directory!
Feel free to share other notes and comments about systemd below!