简述

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

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

经过查找,对于所有基于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. 小熊派开发实践丨小熊派+合宙Cat.1接入云服务器

    摘要:使用小熊派开发板,以合宙的AIR724为通信模组(Cat.1),以AT指令方式,通过mqtt协议接入云服务器. 本贴使用小熊派开发板+合宙的Air724(Cat.1模组),接入自己搭建的EMQ服 ...

  2. 案例展示自定义C函数的实现过程

    摘要:用户在使用数据库过程中,受限于内置函数的功能,部分业务不易实现时,可以使用自定义C函数实现特殊功能.本文通过两个示例展示自定义C函数的实现过程. 前言 用户在使用数据库过程中,常常受限于内置函数 ...

  3. DTT第7期直播回顾 | 低代码应用构建流程和适用场景,与你想的一样吗?

    摘要:本期直播主题是<揭秘华为云低代码技术微认证>,向开发者们讲述低代码的发展历程,介绍华为低代码平台应用魔方AppCube的开发能力,解读华为低代码的认证和学习体系 本期直播详解 本期直 ...

  4. 华为云GaussDB:发挥生态优势,培养应用型DBA

    摘要:GaussDB首要的任务是解决华为的业务连续性的需求,同时也是要确保使用GaussDB的客户的业务能够连续,所以我们坚持战略投入,坚持从每一行代码,坚持从生态开始来构建整个数据库体系. 本文分享 ...

  5. presto是如何保证作业内存不会发生冲突和溢出

    摘要:presto计算引擎作为一个纯内存计算引擎,是如何保证计算过程不会发生作业内存溢出的?本篇文章会进行深入的学习和分析. 本文分享自华为云社区<presto是如何保证作业内存不会发生冲突和溢 ...

  6. 在Spark Scala/Java应用中调用Python脚本,会么?

    摘要:本文将介绍如何在 Spark scala 程序中调用 Python 脚本,Spark java程序调用的过程也大体相同. 本文分享自华为云社区<[Spark]如何在Spark Scala/ ...

  7. 火山引擎 DataTester:A/B 实验如何实现人群智能化定向?

    更多技术交流.求职机会,欢迎关注字节跳动数据平台微信公众号,回复[1]进入官方交流群 在精细化运营时代,用户需求和业务场景愈加多元,在产品功能迭代以及各类活动中,面向不同人群的兴趣点,有针对性地&qu ...

  8. python 升级后 yum 无法使用 File "/usr/bin/yum", line 30 except KeyboardInterrupt, e: `/usr/libexec/urlgrabber-ext-down`

    原因为升级python后新建了软连接指向了新版本,除非同时升级yum不然无法使用.需要手动更改报错文件指向新版本后即可解决. [root@localhost pdserving]# yum insta ...

  9. 浅谈splice( )与slice( )

    1.splice( ) 概念:splice( )用于修改原始数组,它可以删除.插入.替换数组的元素,并返回被删除的元素组成的新数组. 语法:splice(start,deleteCount,item1 ...

  10. 使用 Serverless Devs 插件快速部署前端应用

    作者| 邓超 Serverless Devs 开源贡献者 背景 我们在 上文 [Aliyun] [FC] 如何使用 @serverless-devs/s 部署静态网站到函数计算 中,详细的介绍了如何通 ...