如何在Linux中分析性能 Linux systemd-analyze诊断

P粉602998670

发布时间：2025-08-30 10:01:01

950人浏览过

来源于php中文网

原创

答案：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中分析性能 linux systemd-analyze诊断

在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诊断：

Autoppt

Autoppt：打造高效与精美PPT的AI工具

下载

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 %s\n", comm, str(args->filename)); }'
```
这个工具的学习曲线有点陡峭，但一旦掌握，它能提供前所未有的洞察力。
结合监控系统进行趋势分析： 单次性能分析只能反映某个时间点的状态。将性能指标（如CPU利用率、内存使用、磁盘I/O、网络流量）整合到像Prometheus + Grafana这样的监控系统中，可以让你看到长期的趋势，发现周期性问题，并在问题发生前收到预警。
理解
```
cgroups
```
对性能的影响：
```
cgroups
```
（Control Groups）是Linux用来限制、审计和隔离进程组资源（CPU、内存、I/O等）的机制。如果你在一个容器化环境（如Docker、Kubernetes）中进行性能分析，需要注意
```
cgroups
```
的限制可能已经影响了你的应用性能。资源不足的
```
cgroup
```
可能会导致应用性能下降，即使宿主机资源充足。