重新启动 Linux 服务器所需的时间

Question 1

我假设您使用的是 CentOS 7+ 或 Ubuntu 15.04+，它们都带有 systemd。 Systemd 有一些很棒的工具可以计算出系统启动所需的时间，并通过一些可视化工具来了解原因。

对于最基本的输出，只需运行systemd-analyze，您就会得到一个很好的摘要，如下所示

Startup finished in 853ms (kernel) + 3min 50.610s (initrd) + 10.345s (userspace) = 4min 1.809s

这可以告诉您 systemd 启动后上次启动花费了多长时间。这没有考虑 BIOS/硬件初始化或 GRUB 超时，但对于实际操作系统启动时间应该是准确的。

如果您想找出操作系统花费这么长时间的原因，请尝试systemd-analyze blame这将为您提供从运行时间最长到最短的服务图表。例如从我的系统

3min 49.219s systemd-cryptsetup@luks\x2d62611c1c\x2d74ab\x2d4be9\x2d8990\x2d41c0fd863b5a.service
      5.315s plymouth-quit-wait.service
      3.084s systemd-udev-settle.service
      2.275s plymouth-start.service
      2.256s docker.service
      1.819s powertop.service
       778ms firewalld.service
       676ms dev-mapper-fedora\x2droot.device
       621ms abrtd.service
       493ms lvm2-monitor.service

看起来我的笔记本电脑启动需要 4 分钟，其中 3 分钟是因为我有一个加密的驱动器。

最后，systemd-analyze critical-chain您可以看到一系列被认为对系统启动“至关重要”的事件。来自手册页关键的意思是“时间关键的单元链”。这是因为 systemd 并行化了许多服务。这将列出必须等待另一个单元的单元以及启动所需的时间。

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 @10.336s
└─multi-user.target @10.323s
  └─docker.service @4.900s +2.256s
    └─network.target @4.868s
      └─wpa_supplicant.service @4.828s +14ms
        └─dbus.service @3.753s
          └─basic.target @3.749s
            └─sockets.target @3.749s
              └─docker.socket @3.741s +6ms
                └─sysinit.target @3.737s
                  └─systemd-update-utmp.service @3.726s +10ms
                    └─auditd.service @3.713s +9ms
                      └─systemd-tmpfiles-setup.service @3.617s +82ms
                        └─fedora-import-state.service @3.568s +36ms
                          └─local-fs.target @3.560s
                            └─run-user-42.mount @5.753s
                              └─local-fs-pre.target @383ms
                                └─systemd-tmpfiles-setup-dev.service @301ms +80ms
                                  └─kmod-static-nodes.service @268ms +10ms
                                    └─system.slice
                                      └─-.slice

您还可以通过将引导树导出到图片以通过电子邮件发送或使用 svg 绘制来完成一些很酷的事情。有关更多详细信息，请参阅手册页或这个相关问题了解更多详细信息。

Answer

我假设您使用的是 CentOS 7+ 或 Ubuntu 15.04+，它们都带有 systemd。 Systemd 有一些很棒的工具可以计算出系统启动所需的时间，并通过一些可视化工具来了解原因。

对于最基本的输出，只需运行systemd-analyze，您就会得到一个很好的摘要，如下所示

Startup finished in 853ms (kernel) + 3min 50.610s (initrd) + 10.345s (userspace) = 4min 1.809s

这可以告诉您 systemd 启动后上次启动花费了多长时间。这没有考虑 BIOS/硬件初始化或 GRUB 超时，但对于实际操作系统启动时间应该是准确的。

如果您想找出操作系统花费这么长时间的原因，请尝试systemd-analyze blame这将为您提供从运行时间最长到最短的服务图表。例如从我的系统

3min 49.219s systemd-cryptsetup@luks\x2d62611c1c\x2d74ab\x2d4be9\x2d8990\x2d41c0fd863b5a.service
      5.315s plymouth-quit-wait.service
      3.084s systemd-udev-settle.service
      2.275s plymouth-start.service
      2.256s docker.service
      1.819s powertop.service
       778ms firewalld.service
       676ms dev-mapper-fedora\x2droot.device
       621ms abrtd.service
       493ms lvm2-monitor.service

看起来我的笔记本电脑启动需要 4 分钟，其中 3 分钟是因为我有一个加密的驱动器。

最后，systemd-analyze critical-chain您可以看到一系列被认为对系统启动“至关重要”的事件。来自手册页关键的意思是“时间关键的单元链”。这是因为 systemd 并行化了许多服务。这将列出必须等待另一个单元的单元以及启动所需的时间。

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 @10.336s
└─multi-user.target @10.323s
  └─docker.service @4.900s +2.256s
    └─network.target @4.868s
      └─wpa_supplicant.service @4.828s +14ms
        └─dbus.service @3.753s
          └─basic.target @3.749s
            └─sockets.target @3.749s
              └─docker.socket @3.741s +6ms
                └─sysinit.target @3.737s
                  └─systemd-update-utmp.service @3.726s +10ms
                    └─auditd.service @3.713s +9ms
                      └─systemd-tmpfiles-setup.service @3.617s +82ms
                        └─fedora-import-state.service @3.568s +36ms
                          └─local-fs.target @3.560s
                            └─run-user-42.mount @5.753s
                              └─local-fs-pre.target @383ms
                                └─systemd-tmpfiles-setup-dev.service @301ms +80ms
                                  └─kmod-static-nodes.service @268ms +10ms
                                    └─system.slice
                                      └─-.slice

您还可以通过将引导树导出到图片以通过电子邮件发送或使用 svg 绘制来完成一些很酷的事情。有关更多详细信息，请参阅手册页或这个相关问题了解更多详细信息。

Question 2

7年零4个月前提问

这将取决于服务器正在使用，以及 BIOS/EFI 初始化期间可能花费的时间以及任何RAID 磁盘初始化;这两个是我经历过的大人物。但可能还会发生其他事情，这些事情会占用时间，而这些事情都与 Linux 无关。

RHEL/Centos 7 及更高版本，在启动过程中通常会挂在 systemd 上等待网络，如果您在工作并且拥有公司互联网，有时网络交换机/路由器不会立即向您的服务器授予 dhcp IP 地址，这可能会吃掉至少 30 秒。

确定预期重新启动时间的最简单方法是通过 ssh 输入 putty，然后键入“reboot”。从该点reboot <enter>标记时间，然后从另一个窗口开始ping myserver并等待，直到得到响应。区别在于你预期的时间，做很多次，看看它有多少变化。

一旦 ping 开始响应，并不一定意味着您可以立即登录，因为 SSH 和 GDM 等其他服务尚未启动，但通常会在大约 5 秒内启动，但您会简单地知道是否可以成功登录那么从成功登录到重启后按回车的时间就是你的时间了。

reboot此外，如果必须将数据写入磁盘，或者某些 NFS 服务必须超时，则在键入后关闭时可能会出现明显的延迟。

在关机和启动过程中可能会发生许多合法的事情，这会消耗一些时间。当使用 SLES 11.4 时，EXT4 文件系统与使用 XFS 的 RHEL 7/8 相反，我会遇到fsck has not been run in ~30 days一些 cr@p，所以如果服务器 100 多天没有重新启动（这并不罕见），那么启动时运行的 fsck如果是一个巨大的旋转磁盘，可能需要 30 分钟。

根据我的经验，我知道通常不到 5 分钟是可以预期的，服务器 BIOS 和磁盘 raid 大约需要 3 分钟，对于 RHEL 7/8 的 grub 菜单中的 linux 不到 1:30。如果 10 分钟过去了，我就会去服务器机房，查看控制台上发生的情况（或通过 IPMI 或 iDRAC 查看）以了解发生了什么情况。

Answer