扫码关注
FY EDU / INTERVIEW SERIES / LINUX / BOOT
嵌入式Linux面试：系统启动太慢怎么定位？systemd-analyze和dmesg怎么用？
“启动慢”并不一定是内核问题。Bootloader、内核初始化、文件系统挂载、systemd服务和业务应用都可能占时间，面试官想听到分阶段、可量化的排查方法。
一台Linux设备从上电到应用界面需要30秒，你会怎么找到耗时点？
参考回答
先把启动过程拆成BootROM/Bootloader、内核、用户空间初始化和业务应用几个阶段，建立统一时间基准。对systemd系统，使用systemd-analyze time、blame和critical-chain分析用户空间启动；结合dmesg或journalctl查看内核和服务日志。注意blame显示的是单个服务启动耗时，不代表该服务一定在关键路径上；真正影响总启动时间的往往是依赖链和并行关系。
01先区分慢在哪个阶段
串口日志可以帮助观察Bootloader和内核启动节点，必要时给关键阶段增加时间戳。
systemd-analyze time可提供内核和用户空间初始化的总体统计，但不一定涵盖设备上电到Bootloader之前的全部时间。
如果没有systemd，则要用该发行版实际的init体系和启动脚本排查，不能机械照搬systemd命令。
02三个常用命令各自看什么
systemd-analyze blame：按单元激活耗时排序，适合找明显慢的服务，但并行启动会让单项耗时之和大于总时间。
systemd-analyze critical-chain：查看达到目标单元的关键依赖链，判断哪个服务确实阻塞后续启动。
dmesg -T、journalctl -b及相关时间戳：观察驱动探测、设备超时、挂载和服务报错；对时钟尚未校准的系统，应谨慎解读墙上时间。
03优化之前先确认副作用
可以考虑延迟非关键服务、减少等待超时、调整并行度和优化文件系统挂载，但要检查服务依赖关系。
每次改动都用同一硬件、同一冷启动条件重复测量，记录从上电到业务真正可用的时间，而不是只看桌面出现时间。
看到systemd-analyze blame里某服务耗时最长就直接禁用，没有确认它是否处于关键路径，也没检查业务依赖。
如果systemd显示用户空间启动只花3秒，但整机上电要25秒才能使用，你下一步会检查哪一段？
常见追问 FAQ
systemd-analyze blame的耗时能直接相加吗？
不能。服务可能并行启动，耗时总和并不等于启动总时间。
相关业务入口
电子设计岗位学习与实战课程
