简述

今天有同事咨询:项目上有台服务器操作系统启动时间较长,如何分析?

果然,好问题都来自实践。

经过查找,对于所有基于systemd的系统,可以使用systemd-analyze来分析系统启动时间。查看man手册,systemd-analyze blame和 systemd-analyze critical-chain可以有效分析

 systemd-analyze blame:
This command prints a list of all running units, ordered by the time they took to initialize. This information may be used to optimize boot-up times. systemd-analyze critical-chain:
This command prints a tree of the time-critical chain of units (for each of the specified UNITs or for the default target otherwise). 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.

样例分析

服务器1

配置:四路X86服务器

操作系统:CentOS Linux release 8.5.2111

#  systemd-analyze blame|head -n 15
50.902s unbound-anchor.service
21.032s mysql-monitor-agent.service
15.143s DmServiceDMSERVER.service
15.137s DmAPService.service
10.305s kdump.service
8.214s systemd-udev-settle.service
6.170s NetworkManager-wait-online.service
6.032s mysql-monitor-server.service
4.536s mysqld.service
2.194s dnf-makecache.service
2.117s tuned.service
1.328s dracut-initqueue.service
1.226s lvm2-monitor.service
813ms rdma-load-modules@rdma.service
672ms lvm2-pvscan@8:3.service # systemd-analyze critical-chain unbound-anchor.service
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. unbound-anchor.service +50.902s
└─basic.target @9.108s
└─sockets.target @9.108s
└─spice-vdagentd.socket @9.108s
└─sysinit.target @9.105s
└─systemd-update-utmp.service @9.100s +5ms
└─auditd.service @9.053s +45ms
└─systemd-tmpfiles-setup.service @9.024s +24ms
└─import-state.service @9.010s +13ms
└─local-fs.target @9.009s
└─boot.mount @8.956s +53ms
└─systemd-fsck@dev-disk-by\x2duuid-e2c118b0\x2dc161\x2d4599\x2dacfe\x2dd574ba48cb64.service >
└─local-fs-pre.target @8.923s
└─lvm2-monitor.service @245ms +1.226s
└─dm-event.socket @234ms
└─-.mount
└─system.slice
└─-.slice

服务器2

配置:四路X86服务器

操作系统:CentOS Linux release 7.9.2009 (Core)

# systemd-analyze blame|head -n 15
1min 41.449s network.service
50.468s unbound-anchor.service
38.996s initial-setup.service
27.898s kdump.service
6.214s NetworkManager-wait-online.service
4.439s systemd-udev-settle.service
3.237s tuned.service
2.922s dev-mapper-centos\x2droot.device
1.715s lvm2-pvscan@8:3.service
1.112s containerd.service
1.005s docker.socket
1.004s lvm2-monitor.service
859ms dracut-initqueue.service
814ms postfix.service
756ms fwupd.service # systemd-analyze critical-chain network.service
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. network.service +1min 41.449s
└─network-pre.target @7.418s

服务器3

配置:2路 Phytium服务器

操作系统:Kylin Linux Advanced Server release V10 (Sword)

# systemd-analyze blame|head -n 15
19.884s NetworkManager-wait-online.service
14.006s rasdaemon.service
6.587s dracut-initqueue.service
3.324s kdump.service
2.607s plymouth-quit-wait.service
1.930s network.service
1.525s tuned.service
1.475s lvm2-monitor.service
995ms pmcd.service
791ms hdd.mount
637ms lvm2-pvscan@8:3.service
574ms initrd-switch-root.service
560ms systemd-sysctl.service
540ms dracut-pre-pivot.service
510ms udisks2.service # systemd-analyze critical-chain NetworkManager-wait-online.service
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character. NetworkManager-wait-online.service +19.884s
└─NetworkManager.service @4.107s +66ms
└─network-pre.target @4.104s

服务器4

配置:2路 鲲鹏服务器

操作系统:NFS Server release 3.1 (RTM4-A1)

# systemd-analyze blame|head -n 15
47.635s systemd-fsck-root.service
26.005s NetworkManager-wait-online.service
8.968s plymouth-quit-wait.service
2.028s lvm2-pvscan@8:3.service
1.709s docker.service
1.650s fwupd.service
1.081s postfix.service
1.038s systemd-udev-settle.service
935ms lvm2-monitor.service
877ms dev-mapper-nfs\x2d\x2d3.1\x2droot.device
614ms tuned.service
590ms bolt.service
505ms rdma.service
496ms containerd.service
427ms network.service # systemd-analyze critical-chain systemd-fsck-root.service
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. systemd-fsck-root.service +47.635s
└─systemd-readahead-replay.service @1.257s +39ms
└─system.slice
└─-.slice

[1036]Linux启动时间分析的更多相关文章

  1. linux内核分析作业8:理解进程调度时机跟踪分析进程调度与进程切换的过程

    1. 实验目的 选择一个系统调用(13号系统调用time除外),系统调用列表,使用库函数API和C代码中嵌入汇编代码两种方式使用同一个系统调用 分析汇编代码调用系统调用的工作过程,特别是参数的传递的方 ...

  2. Linux内核分析作业7:Linux内核如何装载和启动一个可执行程序

            1.可执行文件的格式 在 Linux 平台下主要有以下三种可执行文件格式: 1.a.out(assembler and link editor output 汇编器和链接编辑器的输出) ...

  3. linux内核分析作业6:分析Linux内核创建一个新进程的过程

    task_struct结构: struct task_struct {   volatile long state;进程状态  void *stack; 堆栈  pid_t pid; 进程标识符  u ...

  4. linux内核分析作业5:分析system_call中断处理过程

    1.增加 Menu 内核命令行 调试系统调用. 步骤:删除menu git clone        (tab) make rootfs 这就是我们将 fork 函数写入 Menu 系统内核后的效果, ...

  5. linux内核分析作业:以一简单C程序为例,分析汇编代码理解计算机如何工作

    一.实验 使用gcc –S –o main.s main.c -m32 命令编译成汇编代码,如下代码中的数字请自行修改以防与他人雷同 int g(int x) { return x + 3; } in ...

  6. linux内核分析作业:操作系统是如何工作的进行:完成一个简单的时间片轮转多道程序内核代码

    计算机如何工作 三个法宝:存储程序计算机.函数调用堆栈.中断机制. 堆栈 函数调用框架 传递参数 保存返回地址 提供局部变量空间 堆栈相关的寄存器 Esp 堆栈指针  (stack pointer) ...

  7. linux内核分析作业3:跟踪分析Linux内核的启动过程

    内核源码目录 1. arch:录下x86重点关注 2. init:目录下main.c中的start_kernel是启动内核的起点 3. ipc:进程间通信的目录 实验 使用实验楼的虚拟机打开shell ...

  8. linux内核分析作业4:使用库函数API和C代码中嵌入汇编代码两种方式使用同一个系统调用

    系统调用:库函数封装了系统调用,通过库函数和系统调用打交道 用户态:低级别执行状态,代码的掌控范围会受到限制. 内核态:高执行级别,代码可移植性特权指令,访问任意物理地址 为什么划分级别:如果全部特权 ...

  9. 《Linux内核分析》期末总结

    Linux内核设计期中总结 版权声明:本文为博主原创文章,未经博主允许不得转载. 前八周博客汇总及总结 Linux内核设计第一周——从汇编语言出发理解计算机工作原理 我们学习了汇编语言的基础知识,这一 ...

  10. 《Linux及安全》期中总结&《Linux内核分析》期终总结

    [5216 原创作品转载请注明出处 <Linux内核分析>MOOC课程http://mooc.study.163.com/course/USTC-1000029000] WEEK NINE ...

随机推荐

  1. CANN开发实践:4个DVPP内存问题的典型案例解读

    摘要:由于DVPP媒体数据处理功能对存放输入.输出数据的内存有更高的要求(例如,内存首地址128字节对齐),因此需调用专用的内存申请接口,那么本期就分享几个关于DVPP内存问题的典型案例,并给出原因分 ...

  2. 云小课|MRS基础原理之ClickHouse组件介绍

    阅识风云是华为云信息大咖,擅长将复杂信息多元化呈现,其出品的一张图(云图说).深入浅出的博文(云小课)或短视频(云视厅)总有一款能让您快速上手华为云.更多精彩内容请单击此处. 摘要:在2016年开源的 ...

  3. 华为云企业级Redis揭秘第15期:Redis为什么需要强一致?

    摘要:其实开源Redis的弱一致性已经不满足很多应用场景的诉求.怎么,不信? 本文分享自华为云社区<华为云企业级Redis揭秘第15期:Redis为什么需要强一致?>,作者: GaussD ...

  4. Scala学习系列(二)——环境安装配置

    Scala下载地址:https://www.scala-lang.org/download/ 一.安装JDK 首先,因为Scala是运行在JVM平台上的,所以安装Scala之前要安装JDK 二.二进制 ...

  5. 火山引擎 VeDI 零售行业解决方案 聚焦精准营销场景提升品牌转化

    更多技术交流.求职机会,欢迎关注字节跳动数据平台微信公众号,回复[1]进入官方交流群 你知道,为了能让你买到合适的商品,品牌商们有多努力吗? 精准营销并不是一个新词,但近年来,随着营销渠道/平台的更加 ...

  6. Solon 运行出乱码怎么办?

    1.启动时添加 -Dfile.encoding=utf-8,示例: java -Dfile.encoding=utf-8 -jar DemoApp.jar 再出现乱码?一般是文件本身编码问题.检查一下 ...

  7. Visual Studio 2022 激活,安装教程,内附Visual Studio激活码、密钥

    visual studio 2022(vs 2022)是由微软官方出品的最新版本的开发工具包系列产品.它是一个完整的开发工具集,囊括了整 visual studio 2022是一款由微软全新研发推出的 ...

  8. PS CJ20N 项目定义属性字段增强

    一.CJ20N添加字段  二.用户出口  三.校验必输项 博客频遭盗窃,请移步公众号"斌将军",输入关键字"项目定义字段增强"查看 TRANSLATE with ...

  9. Python 使用pip或easy_install或手动安装库/模块/软件包

    pip是easy_install的改进版,提供更好的提示信息,删除package等功能.老版本的python中只有easy_install,没有pip.本文主要介绍使用pip或easy_install ...

  10. Printer Queue,UVa 12100 (自定义标记法 + 优先队列)

    题目描述: 我们需要用打印机打印任务.每个任务都有1~9间的优先级,优先级越高,任务越急. 打印机的运作方式:从打印队列里取出一个任务j,如果队列里有比j更急的任务,则直接把j放到打印队列尾部,否则打 ...