我是某大型跨境电商的系统运维工程师。我们在香港部署了一批物理服务器，主要承担海外用户的高并发业务请求。2024年年底，我们新上线一批搭载Intel Ice Lake平台的裸金属服务器，运行的是定制优化后的Ubuntu 22.04 LTS。然而上线不久后就出现了问题：这批机器从上电到操作系统完成初始化，比原先预期慢了近40秒。

40秒听起来不算多，但在大规模自动化部署、故障切换、裸机调度平台的场景下，这样的启动延迟不可接受。初步排查没有发现明显的系统级错误，因此我决定采用系统自带工具，对启动链路从BIOS到OS进行逐步剖析。这篇文章记录了我在这次问题排查中的完整实操流程、工具使用、踩坑经历与最终的解决方案。

一、明确目标：定义启动链路性能的分析边界

启动链路可以分为几个主要阶段：

• BIOS/UEFI初始化阶段
• POST（Power-On Self-Test）阶段
• Bootloader 加载（如GRUB）
• 内核加载与初始化
• 用户空间初始化（systemd）

我的目标是找到“慢”出现在了哪一个阶段。要实现这一点，关键在于抓到每个阶段的时间戳。

二、分析思路：用系统原生工具逐段拆解

不借助商业APM或第三方探针，我选择只使用系统原生工具。原因有三：

• 香港数据中心的安全规范严苛，禁止使用外部上传工具。
• 启动路径分析不需要常驻 agent，只需一次性抓取即可。
• 系统工具已足够精准，关键在于理解其输出。

三、实操步骤详解

1. BIOS/UEFI阶段：开启Debug日志、抓取启动时间

首先我登录iDRAC（Dell服务器）远程管理口，设置如下：

• 进入 BIOS 设置 > Boot Options
• 启用 Verbose Boot Mode 和 UEFI Boot Diagnostics
• 设置 BIOS POST Detail Level 为 Full Diagnostics

保存并重启后，iDRAC的日志系统（Lifecycle Log）会记录BIOS从上电到完成UEFI引导总共耗时。例如：

[Timestamp] BIOS Initialization Start
[Timestamp] POST Complete
[Timestamp] Handoff to Bootloader (UEFI Shell)

此处我提取出从上电到handoff总计耗时 19.3 秒，明显比正常 BIOS 时长（约7秒）长。

我进一步导出 SupportAssist Collection Log，解压后查看 bios.log 和 postcode.log，看到大量 Memory Training 和 PCIe Bus Enumeration 的延迟日志，推测硬件初始化阶段存在瓶颈。

2. GRUB Bootloader：启用时间日志记录

在 /etc/default/grub 中添加如下参数：

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash initcall_debug printk.time=y"

更新 grub：

sudo update-grub

这会在系统启动时记录详细的内核初始化与驱动注册时间。重启后查看 /var/log/dmesg 输出：

dmesg --color=always | less

我们重点关注 early boot 的耗时区段：

[    0.000000] Linux version ...
[    2.321344] pci_bus 0000:00: resource ...
[   12.731902] initcall init_pcie_devices+0x0 returned 0 after 10487 usecs

这里发现部分 PCIe 设备初始化时间明显偏长，尤其是网卡与 RAID 控制器，提示需要进一步分析驱动加载过程。

3. 内核阶段：systemd-analyze 解构启动时间

Ubuntu 默认启用了 systemd，可直接使用：

systemd-analyze

输出示例：

Startup finished in 4.922s (firmware) + 11.831s (loader) + 8.213s (kernel) + 14.512s (userspace) = **39.478s**

systemd-analyze blame 可列出启动项耗时：

sudo systemd-analyze blame | head -n 10

输出中排在前几位的是 networking.service 和 cloud-init-local.service，每项超过6秒，异常明显。

为了进一步细化服务依赖关系，我使用：

sudo systemd-analyze critical-chain

发现 cloud-init-local 阻塞了网络初始化，而后者又依赖于 iscsi 探测，最终链路显示启动被多个串联服务阻塞。

四、性能瓶颈定位与解决方案

问题1：UEFI初始化过慢

原因： 内存模块开启了高级 ECC 检测+Persistent Memory Remap，导致 POST 变慢。

解决： BIOS 中关闭 ECC Scrubbing 与 Memory Mapping for PMEM，仅启用基本校验后，BIOS耗时下降至8秒。

问题2：PCIe设备初始化阻塞

原因： 网卡在 PXE 启动模式下，每次都进行网络发现并等待超时。

解决：

禁用 BIOS 中 PXE Boot

修改 GRUB 中添加 net.ifnames=0 biosdevname=0，加快设备命名初始化

将 initrd 中无用驱动打包至 blacklist.conf

问题3：用户空间服务链路阻塞

原因： cloud-init 探测 iSCSI target 导致串联网络阻塞

解决：

sudo touch /etc/cloud/cloud-init.disabled
sudo systemctl disable cloud-init

若使用 automation tool (如Terraform) 已替代 cloud-init 功能，则建议在 golden image 中直接去除 cloud-init 包：

sudo apt purge cloud-init

五、结果验证与总结

优化后，我再次执行：

systemd-analyze

输出如下：

Startup finished in 4.733s (firmware) + 3.711s (loader) + 3.111s (kernel) + 5.902s (userspace) = **17.457s**

从原先的近40秒降到17秒，接近我们设定的目标。

六、系统工具并不“简陋”，关键在于理解它

这次问题让我再次体会到：不一定要依赖 fancy 的第三方工具，Linux 原生命令、系统日志与 BIOS 设置，本身就具备极强的分析力。

只要掌握这些“原生刀”，就可以从容应对启动链路中的复杂问题。在真实生产环境下，能用系统自带工具完成性能剖析，是运维工程师实战力的体现。

如你有类似的服务器优化需求，建议先从 systemd-analyze 开始，顺着日志链路“逆推”，再结合硬件层调优，往往就能找出“慢”的真正源头。希望这篇实战记录能对你有所帮助。