起動が遅い原因は?そんな時はsystemd-analyzeでチェック
06-03-2015
起動時間が長くなった時、何にそんなに時間がかかってるんだ!と思うことがある。 それを調査してくれるコマンドがあった。 それが、systemd-analyze
使い方は簡単。 systemd-analyze
と打って Enter
を押すだけ。
systemd-analyze
の実行結果1 2 # systemd-analyze Startup finished in 666 ms (kernel ) + 2.171 s (initrd ) + 4.705 s (userspace ) = 7.542 s
kernel, initrd, userspace それぞれの合計時間をだしてくれる。
より詳細を知りたい場合は、blame
オプションを使う。 systemd-analyze blame
の実行結果
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 # systemd-analyze blame 1.120 s firewalld.service 1.032 s network.service 987 ms boot.mount 712 ms tuned.service 574 ms vboxadd.service 458 ms vboxadd-x11.service 320 ms systemd-vconsole-setup.service 293 ms lvm2-monitor.service 189 ms rhel-readonly.service 179 ms systemd-logind.service 168 ms rsyslog.service 141 ms systemd-udev-trigger.service 139 ms systemd-tmpfiles-setup-dev.service 126 ms rhel-dmesg.service 121 ms NetworkManager.service 114 ms auditd.service 102 ms systemd-user-sessions.service 95 ms polkit.service 94 ms kmod-static -nodes.service 86 ms vboxadd-service.service 84 ms systemd-random-seed.service 75 ms sys-kernel-debug.mount 75 ms systemd-sysctl.service 56 ms dev-mqueue.mount 56 ms dev-hugepages.mount 56 ms lvm2-pvscan@8 :2. service 45 ms systemd-tmpfiles-setup.service 34 ms systemd-remount-fs.service 32 ms systemd-journal-flush.service 31 ms sm-client.service 28 ms sendmail.service 18 ms dev-mapper-centos\x2dswap.swap 13 ms systemd-udevd.service 10 ms sys-kernel-config.mount 10 ms systemd-update-utmp-runlevel.service 4 ms systemd-update-utmp.service
起動に時間のかかったユニット順に出力してくれる。
どのユニットが問題か知りたい場合は、 critical-chain
オプション systemd-analyze critical-chain
の実行結果
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 # systemd-analyze critical-chain 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 @4.686 s └─sshd.service @4.436 s └─network.target @4.429 s └─network.service @3.394 s +1.032 s └─NetworkManager.service @3.266 s +121 ms └─firewalld.service @2.139 s +1.120 s └─basic.target @2.130 s └─paths.target @2.128 s └─brandbot.path @2.128 s └─sysinit.target @2.115 s └─systemd-update-utmp.service @2.106 s +4 ms └─auditd.service @1.988 s +114 ms └─systemd-tmpfiles-setup.service @1.936 s +45 ms └─local-fs.target @1.926 s └─boot.mount @936 ms +987 ms └─dev-disk-by\x2duuid-1320e8 a2\x2da3f3\x2d4a2f\x2d8ff6\x2d6c533eee9dd7.device @871 ms
結果をsvgファイルで視覚的に表示するには prot
オプション systemd-analyze plot > result.svg
の実行結果
このように視覚的に出力することも出来る。
詳細なログを出したい時は、 dump
オプション systemd-analyze dump
の実行結果
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 # systemd-analyze dump-> Unit network.service: Description: LSB: Bring up/down networking Instance : n /a Unit Load State: loaded Unit Active State: active Inactive Exit Timestamp : Tue 2015 -06 -02 14 :51 :10 UTC Active Enter Timestamp : Tue 2015 -06 -02 14 :51 :11 UTC Active Exit Timestamp : n /a Inactive Enter Timestamp : n /a GC Check Good: yes Need Daemon Reload: no Transient: no Slice: system .slice CGroup: /system .slice/network.service CGroup realized: yes CGroup mask : 0x0 Name : network.service Source Path : /etc/rc.d /init.d /network Condition Timestamp : Tue 2015 -06 -02 14 :51 :10 UTC Condition Result : yes Requires: basic.target (省略)
詳細を追うことが出来る。
重い原因を特定して、起動を爆速にしてしまおう。
Newer
hexoで日本語のパーマリンクを見れるようにしよう!
Older
swaksで快適なメール送信テスト