在Linux系统运维与性能调优中，开机速度是衡量系统响应能力与效率的重要指标。查看Linux开机时间的核心上文归纳是：对于广泛使用systemd初始化系统的现代Linux发行版（如CentOS 7+、Ubuntu 15.04+、Debian 8+），systemd-analyze命令是查看、分析及定位启动瓶颈最权威、最直观的工具。 它不仅能提供精确到毫秒的总耗时，还能将启动过程拆解为内核空间与用户空间，并可视化各服务的启动依赖关系与耗时,从而为后续的系统优化提供数据支撑。
使用systemd-analyze精准定位启动耗时
systemd-analyze 是systemd套件中专门用于分析启动流程的工具，其输出结果具有极高的可信度,是系统管理员的首选方法。
查看总体启动时间 要获取系统启动的总耗时,只需在终端执行以下命令：
systemd-analyze time
该命令会输出三行关键数据：
- Startup finished in ... (firmware)：固件（BIOS/UEFI）初始化耗时，这部分时间主要由主板硬件决定，若此处耗时过长,通常需要检查BIOS设置或硬件健康状态。
- Startup finished in ... (loader)：引导加载程序（如GRUB）耗时。
- Startup finished in ... (kernel)：Linux内核加载到初始化完成耗时。
- Startup finished in ... (userspace)：用户空间（即系统服务）启动耗时。 通过这种分层展示，我们可以迅速判断是硬件初始化慢、内核加载慢,还是系统服务拖慢了整体速度。
分析各服务启动耗时（关键瓶颈排查） 如果发现用户空间耗时过长，需要进一步定位具体是哪个服务导致的,此时应使用：
systemd-analyze blame
该命令会列出所有在启动过程中运行的服务，并按照耗时从长到短进行排序，每一行显示服务名称和对应的启动时间。这是优化开机速度的核心依据，排在列表顶部的服务就是导致开机慢的“罪魁祸首”，经常发现NetworkManager-wait-online.service或sshd.service在某些配置下耗时较长。
查看关键启动依赖链 单纯看时间排序有时会产生误导，因为某些服务是并行启动的，而有些是串行依赖的，为了理解启动顺序和依赖关系,可以使用：
systemd-analyze critical-chain
该命令以树状图形式展示“关键链”，即那些阻塞了后续服务启动的路径。如果关键链上的某个服务耗时较长，它会产生“多米诺骨牌效应”，直接推迟整个系统的启动完成时间。 优化关键链上的服务,往往比优化非关键链服务能带来更显著的提速效果。
可视化启动流程与日志深度分析
对于追求极致性能或需要进行复杂排错的场景，命令行文本输出可能不够直观,图形化工具和日志检索能提供更丰富的体验。
生成启动可视化图表
systemd-analyze 支持生成SVG格式的启动图表,这能非常直观地展示所有服务的并行启动情况：
systemd-analyze plot > boot.svg
下载生成的boot.svg文件并在浏览器中打开，你会看到一个复杂的时间轴图，图中每一个横条代表一个服务，横条的长度代表耗时，颜色的深浅代表服务的状态。通过观察图表，可以一眼看出哪些时间段CPU处于空闲状态（即存在空档期），或者哪些服务存在严重的串行等待。
利用journalctl查看启动日志
除了systemd工具，journalctl作为systemd的日志系统组件，也能提供启动时间信息，通过查看启动日志,可以结合报错信息来判断启动慢的原因：
journalctl -b -0 -err
-b：指定查看本次启动的日志（-0代表当前启动，-1代表上一次启动）。-err：仅显示错误级别的日志。 如果在启动过程中有服务启动失败并重试，这些错误日志会详细记录下来，往往能解释为什么某些服务在systemd-analyze blame中显示耗时极长。
传统方法与独立见解：非systemd环境与硬件层面
虽然systemd已成为主流，但在某些老旧系统或嵌入式Linux中，仍可能使用SysVinit,很多用户容易忽视硬件层面的时间损耗。
传统方法：dmesg与uptime
在非systemd环境下，或者为了查看内核启动的具体时间点，可以使用dmesg：
dmesg | grep iomem
或者更通用的查看内核启动结束时间：
dmesg | grep "Kernel command line"
但这通常不如systemd-analyze精确，另一个简单的命令是uptime，它能显示系统运行了多久，但这只能作为粗略参考,无法精确反映开机耗时。
独立见解：区分“开机时间”与“可用时间”
很多用户存在一个误区，认为看到登录界面就算开机完成。从专业运维角度看，真正的“开机完成”应当是指系统达到“multi-user.target”或“graphical.target”的状态，即所有核心服务已就绪，网络已连接，可以对外提供服务。
在分析开机时间时，必须关注systemd-analyze time输出的最终一行，如果登录界面出现很快，但进入桌面后鼠标转圈很久，或者网络迟迟不可用，说明后台服务仍在初始化，这种情况下，单纯优化图形界面的启动速度是治标不治本，必须回到blame命令中去检查那些在后台拖沓的网络服务、数据库服务或虚拟化服务。
专业的开机加速解决方案
基于上述分析,我们可以制定一套专业的加速策略。
优化服务并行性
systemd的原生优势是并行启动，如果发现某些服务本应并行却被迫串行，检查其单元文件（Unit File）中的After和Wants配置。移除不必要的依赖关系强制，可以让更多的服务同时启动，从而充分利用多核CPU性能。
禁用不必要的服务 这是最直接的提速手段，对于服务器环境，如果不需要蓝牙服务、打印服务或图形界面服务,应彻底禁用它们：
systemctl disable --now [service-name]
特别注意： 禁用服务前务必确认其不影响业务运行。NetworkManager-wait-online.service在很多服务器上会导致等待长达30秒以获取DHCP租约，如果服务器使用静态IP，可以直接禁用此服务，通常能立竿见影地减少20-30秒的开机时间。
硬盘I/O与固件优化
如果firmware时间过长，检查BIOS中是否开启了不必要的快速启动或大量的硬件自检，如果内核加载时间长，且使用的是机械硬盘，将系统迁移至SSD（固态硬盘）是解决I/O瓶颈的根本性方案，在内核启动参数中加入quiet或splash可以减少文本输出的开销，虽然对时间影响微乎其微,但能提升视觉上的启动体验。
相关问答
Q1：为什么使用systemd-analyze blame查看的时间总和远大于实际开机总时间？
A： 这是因为systemd默认采用并行启动机制。blame命令列出的是每个服务单独消耗的CPU时间或挂起时间，这些时间在时间轴上是重叠的，就像四个人同时干活，每人干了10分钟，但任务总耗时只有10分钟，而不是40分钟，不能简单地将blame列出的时间相加，而应关注其中耗时最长的单条记录,这才是阻塞启动的关键。
Q2：如何查看上一次（而非当前）启动的开机时间？
A： systemd-analyze默认查看的是最后一次启动，要查看上一次启动的时间，可以使用命令 systemd-analyze time -b -1（在某些版本中支持），或者更通用的方法是结合journalctl查看上一次启动的日志时间戳，最简单的方式是直接使用 systemd-analyze 命令，它会列出当前启动的信息；若需对比历史数据，可以使用 systemd-analyze 查看当前，然后重启后对比，或者利用 last reboot 命令查看重启记录来辅助推断历史启动的大致情况，对于精确的历史启动分析，通常需要查看 journalctl -b -1 中的日志来推断服务启动耗时。