答案：Linux性能分析需结合systemd-analyze与多种工具，从启动到运行时全面排查。首先用systemd-analyze查看启动耗时，blame定位慢服务，critical-chain分析关键路径，plot生成可视化图表；运行时则用top/htop、vmstat、mpstat监控CPU，free、vmstat、slabtop分析内存，iostat、iotop检测磁盘I/O，ss、iftop排查网络问题；需避免误读free和load average，建立性能基线，结合perf、strace、bpftrace深入追踪，并通过监控系统实现趋势分析，理解cgroups资源限制影响。
在Linux系统里琢磨性能问题，说白了，就是一场侦探游戏。你得从各种蛛丝马迹中找出瓶颈，无论是CPU、内存、磁盘I/O还是网络。
systemd-analyze
是个不错的起点，它能帮你快速摸清系统启动的家底，但真正的性能分析远不止于此，它需要你结合一系列工具，带着问题去观察、去思考。这不是一蹴而就的事，更像是一种艺术，需要经验和直觉。
解决方案
要深入分析Linux系统的性能，我们通常会从宏观到微观，从启动到运行时，多维度地审视。
首先，
systemd-analyze
是诊断启动性能的利器。
直接运行
systemd-analyze
，它会告诉你内核启动花了多久，用户空间启动花了多久，以及总耗时。这给了一个整体的概念。
systemd-analyze blame
会列出所有systemd单元（服务、挂载点等）从启动到完成所花费的时间，并按降序排列。这非常直观，一眼就能看到哪些服务是“拖油瓶”。
systemd-analyze critical-chain
则展示了启动过程中最关键的依赖链，也就是那些必须串行执行，并且耗时最长的任务。理解这条链，能帮你找到真正的阻塞点。如果你想更直观，
systemd-analyze plot > boot.svg
能生成一张SVG格式的甘特图，将整个启动过程可视化。时间轴上的长条代表服务，它们的并行和串行关系一目了然。
但启动只是系统生命周期的一部分。运行时性能分析需要更多工具：
CPU瓶颈：
top
或
htop
是实时监控的瑞士军刀，关注
%us
（用户空间CPU使用率）、
%sy
（内核空间CPU使用率）、
%wa
（I/O等待）和
load average
。如果
%us
或
%sy
持续高企，说明CPU可能不够用或有计算密集型进程。
vmstat 1
可以查看
r
（运行队列）和
cs
（上下文切换）的情况，高
r
值意味着CPU争抢严重。
mpstat -P ALL 1
能看到每个核心的利用率。内存瓶颈：
free -h
快速查看内存使用概况，注意
Swap
使用量。如果
Swap
频繁被使用，通常意味着物理内存不足。
vmstat 1
中的
si
和
so
（换入/换出）指标也很关键。
ps aux --sort=-%mem
能找出最耗内存的进程。
slabtop
则能深入到内核slab缓存的使用情况。磁盘I/O瓶颈：
iostat -xz 1
是分析磁盘I/O的专业工具。关注
%util
（磁盘利用率，接近100%说明磁盘很忙）、
r/s
和
w/s
（读写请求数）、
rkB/s
和
wkB/s
（读写数据量）、
await
（请求平均等待时间，高值表示延迟大）。
iotop
则能像
top
一样，实时显示哪些进程在进行大量的磁盘I/O。网络瓶颈：
netstat -tulnpa
或
ss -tulnpa
查看监听端口和连接状态。
iftop
（如果安装了）能实时监控网络接口的带宽使用。
ss -s
提供套接字统计摘要，可以快速发现连接过多或异常的情况。
性能分析是个迭代的过程：发现问题 -> 假设原因 -> 验证 -> 优化。它要求你不仅仅是看数字，更要理解这些数字背后的含义。
如何解读
systemd-analyze
的输出，找出启动瓶颈？
systemd-analyze
家族命令，在我看来，是理解Linux系统启动过程的“X光片”。它不像其他工具那样实时监控，而是专注于启动这个特定阶段，帮助我们找出那些让系统慢下来的“罪魁祸首”。
当你运行
systemd-analyze
时，它会给你一个大致的时间分布：
Kernel
、
Initrd
、
Userspace
。通常我们更关心
Userspace
，因为这里是各种服务和应用程序启动的地方，也是最容易出问题的地方。
接下来，
systemd-analyze blame
是你最常用的命令。它的输出是一列按时间降序排列的单元（
unit
），包括服务（
.service
）、挂载点（
.mount
）、设备（
.device
）等等。那些排在最前面的、耗时最长的，就是你首先要关注的对象。比如，你可能会看到一个名为
network-online.target
的服务耗时特别长，这可能意味着你的网络配置有问题，或者依赖的网络服务（如DHCP）响应慢。又或者，某个应用程序的服务，比如
mysql.service
或
docker.service
，启动时间异常长，那你就需要深入检查这个应用程序自身的日志，看它在启动时到底卡在了哪里。
systemd-analyze critical-chain
则提供了一个不同的视角。它不是简单地列出所有耗时长的单元，而是描绘出一条“关键路径”。这条路径上的单元是相互依赖的，它们必须按顺序启动，其中任何一个环节的延迟都会直接影响到最终的启动时间。如果这条链上某个服务耗时过长，那么优化它将对整体启动速度产生显著影响。我经常发现，一些不必要的网络挂载（NFS/SMB）或者一些复杂的udev规则，会出现在这条关键链上，导致启动时间被拉长。
最后，
systemd-analyze plot > boot.svg
生成的SVG图，简直是“一图胜千言”的典范。它用图形化的方式展示了所有单元的启动时间轴。你可以清晰地看到哪些服务是并行启动的，哪些是串行等待的。如果某个长条显得特别突出，或者有大段的空白（表示CPU或I/O在等待），那就说明那里可能存在瓶颈。我个人很喜欢用这个图来向同事解释启动问题，因为它直观易懂，能快速定位到问题区域。
解读这些输出时，关键在于结合你的系统知识。一个服务耗时10秒，这算长吗？这取决于这个服务的功能和它所处的环境。对于一个简单的Web服务器，10秒可能太长；但对于一个需要加载大量数据、进行复杂初始化的数据库服务，10秒可能就比较正常。所以，没有绝对的“长”或“短”，只有相对的“异常”。
除了
systemd-analyze
，还有哪些核心工具可以帮助我诊断Linux系统性能？
systemd-analyze
固然好用，但它毕竟只聚焦于启动过程。当系统已经跑起来，出现性能问题时，我们就需要一套“组合拳”来应对了。在我多年的经验里，以下这些工具几乎是每次性能排查的必备：
CPU诊断：
top
/
htop
： 这是最基础也是最常用的实时监控工具。
top
（或更友好的
htop
）能让你一眼看到CPU利用率、负载平均值（
load average
）和各进程的CPU占用情况。我通常会先看
load average
，如果它持续高于CPU核心数，说明CPU可能过载。然后我会关注
%us
（用户空间）和
%sy
（内核空间）的比例，如果
%sy
过高，可能意味着大量的系统调用或内核任务消耗了CPU。
htop
的彩色界面和进程树视图，能更快地帮你找到异常进程。
vmstat 1
： 这是一个更底层的工具，每秒输出一次系统活动报告。它能告诉你运行队列（
r
，等待CPU的进程数）、上下文切换（
cs
）和中断（
in
）的情况。如果
r
值持续很高，而CPU利用率并没有满，那可能就是I/O等待（
wa
）或锁竞争导致的问题。
mpstat -P ALL 1
： 当你需要了解每个CPU核心的利用率时，
mpstat
就派上用场了。它能帮你判断是某个核心被单线程应用跑满，还是所有核心都处于高负载状态。
内存诊断：
free -h
： 快速查看内存使用情况。关键是理解
available
（可用内存）和
Swap
（交换空间）的使用。很多人看到
free
很少就以为内存不够，但其实Linux会大量使用内存作为缓存（
buff/cache
），这部分是可以被回收的。真正的内存压力是
available
很低且
Swap
频繁使用。
vmstat 1
： 再次提到它，因为它也能显示
si
（换入）和
so
（换出）的页面数量。如果这两个值持续非零，说明系统在频繁地进行内存交换，这会严重拖慢性能，是内存瓶颈的明显信号。
ps aux --sort=-%mem
： 按照内存使用量排序进程，能快速找出哪个进程是内存大户。
slabtop
： 如果内核内存（而非用户进程内存）消耗异常，
slabtop
可以帮你看到内核中各种缓存（slab）的使用情况，这对于调试某些内核模块或文件系统相关的内存泄漏很有用。
磁盘I/O诊断：
如知AI笔记
如知笔记——支持markdown的在线笔记，支持ai智能写作、AI搜索，支持DeepseekR1满血大模型
27 查看详情
iostat -xz 1
： 这是我的首选。它能提供每个磁盘设备的详细I/O统计信息。我主要关注
%util
（磁盘繁忙程度），如果接近100%说明磁盘已是瓶颈。
await
（平均I/O等待时间）也很重要，高
await
值意味着I/O请求处理缓慢。
r/s
、
w/s
、
rkB/s
、
wkB/s
则告诉你读写请求的频率和数据量。
iotop
： 类似于
top
，但专注于显示哪些进程正在进行大量的磁盘读写操作。当你发现磁盘I/O很高，但不知道是哪个应用导致的，
iotop
能帮你快速定位。
网络诊断：
ss -s
/
netstat -s
： 快速获取网络统计摘要，比如TCP连接数、UDP数据包统计等。如果TCP连接处于大量
TIME_WAIT
或
CLOSE_WAIT
状态，可能意味着应用程序或网络配置有问题。
netstat -tulnpa
/
ss -tulnpa
： 查看所有监听端口和建立的连接，以及对应的进程ID。这对于检查是否有未授权服务监听端口，或者某个服务连接数异常高很有用。
iftop
： 如果你想实时监控某个网络接口的带宽使用情况，
iftop
能提供一个非常直观的文本界面，显示哪些IP地址正在消耗你的带宽。
这些工具各有侧重，但它们组合起来，就能为你描绘出系统性能的全貌。关键在于，你不能只看一个指标，而是要综合分析，形成一个完整的性能画像。
在实际性能分析中，我应该关注哪些常见误区和高级技巧？
性能分析这活儿，干久了总会遇到一些坑，也会总结出一些门道。避免误区，掌握一些高级技巧，能让你少走弯路，更快地找到问题的症结。
常见误区：
盲目相信
free
命令的“可用内存”： 很多人看到
free -h
输出中
free
那一行数值很小，就断定内存不足。但Linux为了提高性能，会把大量内存用作文件系统缓存（
buff/cache
）。这部分内存是“可用的”，系统需要时会立即回收。真正的内存压力是
available
（可用内存）很低，并且
Swap
空间被大量使用。误解
load average
：
load average
不仅仅是CPU负载，它还包含了等待I/O的进程。所以，即使
load average
很高，CPU利用率却很低，这往往意味着系统正在等待磁盘I/O完成，而不是CPU本身是瓶颈。只关注症状，不追溯根源： 比如，看到某个进程CPU使用率高，就直接去杀掉它。但这个进程为什么会高？它是不是在执行某个必要的任务？它是不是被其他进程或外部请求触发的？不找到根源，问题很可能再次出现。缺乏基线（Baseline）： 没有正常运行时的性能数据作为参照，你很难判断当前的“高”或“低”是否真的异常。定期收集系统性能指标，建立一个基线，是性能分析的第一步。过度优化非瓶颈： 投入大量精力去优化一个并非当前瓶颈的组件，效果微乎其微。性能优化应该始终集中在最慢、最受限的部分。
高级技巧：
使用
perf
进行函数级分析： 当你用
top
发现某个进程CPU占用很高，但不知道它具体在做什么时，
perf
就非常有用了。它能让你深入到函数调用层面，分析哪个函数消耗了最多的CPU周期。
# 记录某个命令的性能数据perf record -F 99 -a sleep 10# 分析数据并显示调用图perf report
这能帮你定位到代码层面的性能瓶颈。
strace
跟踪系统调用：
strace -p
可以实时显示一个进程正在执行的所有系统调用。如果你怀疑一个进程因为频繁的I/O操作、文件访问或网络通信而变慢，
strace
能让你看到它与内核交互的每一个细节。这对于调试应用程序的I/O行为或权限问题特别有效。
bpftrace
/
eBPF
动态追踪： 这是近些年Linux性能分析领域最激动人心的技术之一。
eBPF
（extended Berkeley Packet Filter）允许你在内核运行时动态加载自定义程序，以极低的开销收集各种性能数据，而无需修改内核或重启系统。
bpftrace
是基于
eBPF
的高级追踪语言，你可以用它编写脚本来追踪几乎任何内核或用户空间的事件，比如文件打开、网络包收发、函数调用等。
# 示例：追踪所有进程的openat系统调用bpftrace -e 'tracepoint:syscalls:sys_enter_openat { printf("%s %sn", comm, str(args->filename)); }'
这个工具的学习曲线有点陡峭，但一旦掌握，它能提供前所未有的洞察力。
结合监控系统进行趋势分析： 单次性能分析只能反映某个时间点的状态。将性能指标（如CPU利用率、内存使用、磁盘I/O、网络流量）整合到像Prometheus + Grafana这样的监控系统中，可以让你看到长期的趋势，发现周期性问题，并在问题发生前收到预警。
理解
cgroups
对性能的影响：
cgroups
（Control Groups）是Linux用来限制、审计和隔离进程组资源（CPU、内存、I/O等）的机制。如果你在一个容器化环境（如Docker、Kubernetes）中进行性能分析，需要注意
cgroups
的限制可能已经影响了你的应用性能。资源不足的
cgroup
可能会导致应用性能下降，即使宿主机资源充足。
性能分析是一个持续学习和实践的过程。它没有一劳永逸的解决方案，更多的是一种思维方式：带着疑问去观察，用工具去验证，用数据去说话。
以上就是如何在Linux中分析性能 Linux systemd-analyze诊断的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/437499.html
微信扫一扫 
支付宝扫一扫 
