Linux 性能调优系列（四）：别只会用 sysstat，PCP 才是 Linux 性能监控的进阶玩法
1 | 作者：李晓辉 |
上一篇文章，我们学习了 Linux 中非常经典的性能工具包 sysstat。通过 iostat、mpstat、pidstat 和 sar，我们已经可以完成大量日常性能排查工作，比如：
- 查看历史 CPU 使用率
- 分析磁盘 IO 是否存在瓶颈
- 定位单个进程的资源消耗
- 查看系统负载变化
- 分析网络流量
- 回放某个时间段的系统状态
对于一台普通 Linux 服务器来说，sysstat 已经非常够用了。但是，服务器数量一多，问题就开始出现了。
比如现在公司有 50 台服务器，我们不仅要看 CPU、内存、磁盘和网络，还想进一步监控：
- 容器
- NFS
- 数据库
- Web 服务
- 应用程序
- KVM 虚拟化
- 文件系统
- 其他业务指标
这个时候，如果还完全依赖 sar、iostat、pidstat 这一套工具，就会慢慢感觉有点力不从心。所以这一篇，我们再认识一个 Linux 性能领域非常经典的工具：PCP —— Performance Co-Pilot。
sar、iostat、pidstat 都能看性能了，我为什么还要学一个 PCP？这个问题没有错。实际上，如果你只是维护一台或者几台 Linux 服务器，遇到问题临时排查一下，sysstat 确实已经非常好用。但是，当环境开始变复杂之后，sysstat 的一些局限性就会慢慢暴露出来。
- 指标比较分散
CPU、内存、磁盘、网络、进程分别对应不同命令。
比如：
1 | CPU → mpstat |
平时排查问题当然没什么。但是如果现在出现一个复杂问题：
“下午 2 点左右服务器开始变卡，到底是 CPU、内存、磁盘还是网络导致的？”
这时候你可能需要不断切换不同工具。
- 历史数据虽然有，但管理方式比较传统
sar 可以保存历史数据，这一点非常好。但是这些数据主要还是以 sysstat 自己的日志文件形式存在。当服务器数量越来越多以后：
1 | 服务器1 |
你会发现：
“我到底应该去哪台机器找哪一天的数据？”
这时候就开始有点麻烦了。
- 可视化能力比较有限
sar、iostat 等工具非常适合命令行排查。但是如果你想把下面这些全部画在一个页面上，然后观察它们之间的变化关系，传统命令行工具就不是特别擅长了：
1 | CPU |
- 复杂指标之间的关联分析比较麻烦
实际生产环境中，性能问题很少只有一个指标异常。
比如：
1 | 磁盘 IO 上升 |
如果只看 CPU，很可能会误判。如果只看 Load，也只能知道系统确实忙，但不知道为什么忙。真正排查的时候，需要把多个指标放到一起分析。而这恰恰就是 PCP 比传统性能工具更有价值的地方。
- 多服务器环境需要更加统一的性能数据体系
假设你现在管理 100 台 Linux 服务器。
你肯定不希望每天：
1 | ssh server01 |
然后自己把这些数据拼到一起。这时候，就需要一个更加统一的性能数据体系。而 PCP，就是专门解决这一类问题的。
PCP 到底是什么？
PCP 全称：
Performance Co-Pilot
它是一套开源的系统性能监控与分析框架。PCP 最早由 SGI 发展而来，后来进入 Linux 生态，现在已经成为 Linux 性能分析领域比较经典的一套工具体系。
它和 sysstat 最大的区别在于：
PCP 不只是提供几个性能命令，而是围绕“性能指标”建立了一套完整的采集、查询、存储、回放和可视化体系。
PCP 可以采集很多类型的性能数据，例如：
- CPU
- 内存
- 磁盘
- 网络
- 进程
- 文件系统
- NFS
- 容器
- 数据库
- Web 服务
- KVM
- 应用程序
而且 PCP 采用了一套非常灵活的扩展机制，这套机制就是 PMDA。
从整体上来看，可以把 PCP 理解成这样：
flowchart TB
A[Linux / 应用 / 容器 / 数据库] --> B[PMDA<br/>性能指标采集代理]
B --> C[pmcd<br/>性能指标管理服务]
C --> D[pminfo<br/>查询指标名称]
C --> E[pmval<br/>查询指标值]
C --> F[pcp dstat<br/>综合性能查看]
C --> G[pmlogger<br/>历史数据采集]
G --> H[PCP Archive<br/>历史性能数据]
H --> I[pmval -a<br/>历史数据回放]
H --> J[pmchart<br/>图形分析]
C --> K[pmproxy<br/>访问代理]
K --> L[Grafana<br/>可视化监控]如果你第一次接触 PCP，不需要急着把这些命令全部背下来。
先记住一条主线：
1 | PMDA |
理解这条链路以后，后面的命令就很好理解了。
PCP 的核心架构
PCP 里面有几个名字非常容易让初学者混淆：
1 | pmcd |
我们先不要急着记命令，可以用一个比较生活化的方式理解。
假设现在有一家大型医院。医院里面有：
1 | 心电图科 |
不同科室负责不同的数据。PCP 也是一样。不同的 PMDA 就像医院里面的不同科室，它们负责不同领域的性能指标。而 pmcd 可以理解成医院的总服务台。
客户端过来：
“我要查 CPU。”
pmcd 就去找对应的指标来源。
客户端又说：
“我要查磁盘。”
pmcd 再去找负责磁盘指标的 PMDA。
而 pmlogger 就像一个录像机。
它把这些性能数据持续保存下来。
以后出现问题，我们就可以把过去某个时间段的数据重新调出来分析。
整个关系可以用下面这张图理解：
flowchart LR
subgraph Collect[指标采集]
A[Linux PMDA]
B[proc PMDA]
C[XFS PMDA]
D[KVM PMDA]
E[其他 PMDA]
end
A --> F[pmcd]
B --> F
C --> F
D --> F
E --> F
F --> G[pminfo]
F --> H[pmval]
F --> I[pcp dstat]
F --> J[pmlogger]
J --> K[PCP Archive]
K --> L[历史回放]
K --> M[pmchart]
F --> N[pmproxy]
N --> O[Grafana]安装pcp
1 | [root@localhost ~]# dnf install pcp pcp-doc -y |
启动一下服务
1 | [root@localhost ~]# systemctl enable --now pmcd |
除了 PCP 基础软件包之外，我建议再安装：
1 | [root@localhost ~]# dnf install pcp-system-tools -y |
这个软件包提供了一些非常实用的 PCP 工具。
对于刚从 sysstat 转过来的同学来说，这里面有一个地方非常友好：PCP 提供了一些和传统 Linux 性能工具使用习惯比较接近的命令。
例如：
| 传统工具 | PCP 对应工具 |
|---|---|
iostat | pcp iostat |
free | pcp free |
dstat | pcp dstat |
所以学习 PCP 并不是说以前学过的 Linux 性能工具全部作废。
相反，原来的性能分析思路依然非常有用，只不过底层的数据体系换成了 PCP。
举个例子来看，查看内存
例如传统 Linux 中我们经常执行：
1 | [root@localhost ~]# free |
现在 PCP 也提供了类似的工具：
1 | [root@localhost ~]# pcp free |
从使用方式上看，和传统 free 非常接近。但是这里的数据已经进入 PCP 的指标体系，所以后续可以和 PCP 的其他指标结合起来分析。
pcp dstat：快速观察系统整体性能
1 | [root@localhost ~]# pcp dstat |
可以看到它同时把 CPU、磁盘、网络、分页、中断、上下文切换等信息放到了一个界面中。这对于快速判断服务器当前到底“忙在哪里”非常方便。
- 每 2 秒采样一次，总共采集 10 次
例如：
1 | [root@localhost ~]# pcp dstat 2 10 |
整个命令大概会持续 20 秒。这种方式非常适合临时观察服务器状态。
比如业务人员说：
这台服务器最近有点卡，你帮我看看。用这个命令观察几十秒，看看 CPU、磁盘、网络等指标有没有明显异常。
- 只查看 CPU 和磁盘
如果现在只想关注 CPU 和磁盘：
1 | [root@localhost ~]# pcp dstat -c -d |
-c：CPU统计-d：磁盘读写统计
- 查看网络
只查看网络：
1 | [root@localhost ~]# pcp dstat -n |
pmcd：PCP 的核心服务
接下来正式进入 PCP 的核心组件。
第一个要理解的就是：
pmcd
pmcd 全称是：
Performance Metrics Collection Daemon
可以把它理解成 PCP 的核心服务。它负责管理各种性能指标来源，并为 PCP 客户端提供统一的指标访问入口。
前面我们已经启动：
1 | [root@localhost ~]# systemctl enable --now pmcd |
注意看这里：
1 | pmda/root |
这些就是不同的 PMDA。
所以可以简单理解成：
1 | pmcd |
pmcd 负责统一管理这些指标来源。
PMDA：负责不同领域的性能指标
PMDA 全称：
Performance Metrics Domain Agent
这个名字看起来比较复杂，其实可以简单理解成：PMDA 就是负责某一个性能指标领域的数据采集代理。
例如：
| PMDA | 作用 |
|---|---|
linux | Linux 系统基础指标 |
proc | 进程相关指标 |
xfs | XFS 文件系统指标 |
jbd2 | JBD2 相关指标 |
kvm | KVM 虚拟化指标 |
docker | Docker 相关指标 |
mysql | MySQL 相关指标 |
postgresql | PostgreSQL 相关指标 |
nginx | Nginx 相关指标 |
不过需要注意：
不同发行版、不同 PCP 版本以及不同安装方式，默认安装和启用的 PMDA 并不完全一样。
所以网上看到别人服务器有：
1 | mysql |
并不意味着你的服务器安装 PCP 后一定会自动拥有这些 PMDA。
具体还是要以当前系统实际安装和加载情况为准。
PCP 的核心组件
PCP 体系中有几个关键组件，理解它们非常重要。
pmcd：性能采集调度守护进程
pmcd 是 PCP 的核心守护进程，负责统一管理所有性能指标。
你可以把它理解成一个性能数据总线：
- 各个采集器把指标交给
pmcd - 客户端工具从
pmcd获取数据 - 历史记录器通过
pmcd采集数据
没有 pmcd，PCP 工具就无法正常工作。
1 | [root@localhost ~]# systemctl status pmcd.service |
pmdaconfig/ 各个 PMDA：性能指标采集代理
PMDA 全称是 Performance Metrics Domain Agent，可以理解为不同领域的“指标采集插件”。
常见 PMDA 包括：
| PMDA | 作用 |
|---|---|
| linux | 采集 Linux 系统基础指标 |
| proc | 从 /proc 文件系统采集进程、内存、CPU 等数据 |
| disk | 采集磁盘 IO 指标 |
| network | 采集网络指标 |
| nfs | 采集 NFS 指标 |
| xfs | 采集 XFS 文件系统指标 |
| docker | 采集容器指标 |
| mysql | 采集 MySQL 指标 |
| postgresql | 采集 PostgreSQL 指标 |
| nginx | 采集 Nginx 指标 |
这就是 PCP 强大的原因，它不是固定写死几个指标，而是通过 PMDA 不断扩展监控范围。
我们直接打开pmcd的主配置文件，就能看到本机预设的PMDA列表。
1 | [root@localhost ~]# cat /etc/pcp/pmcd/pmcd.conf |
配置文件里，第一列就是PMDA名称：root、pmcd、proc、xfs、linux、mmv、jbd2、kvm。
⚠️ 重点区分：
这个配置文件写的是待加载清单，不等于已经成功运行。
配置里写了只是代表pmcd尝试去加载它；有没有加载成功，要结合journalctl -u pmcd日志判断。
前面说了，PMDA 负责提供不同领域的指标。那么问题来了：
“这么多指标，我怎么知道具体叫什么？”
1 | [root@localhost ~]# pminfo | more |
输出开头出现了jbd2.*，就说明 jbd2这个PMDA已经加载成功，并且对外提供指标。
同理，如果看到proc.*、linux.*、xfs.*开头的指标，就代表对应的PMDA插件正常工作。
✅ 小技巧：单独查看某个PMDA的全部指标
想单独看proc（进程相关）所有指标：
1 | [root@localhost ~]# pminfo proc |
pmlogger：记录历史性能数据
现在我们已经知道如何查询实时指标了。但是还有一个非常重要的问题：
如果服务器凌晨 2 点出现故障，而你凌晨 3 点才发现，怎么办？
这时候实时数据已经过去了。所以 PCP 需要一个负责“录像”的组件。
它就是：
pmlogger
pmlogger 的作用就是持续读取 PCP 性能指标，并把它们保存为 PCP Archive。
整个过程可以理解成：
flowchart LR
A[PMDA] --> B[pmcd]
B --> C[pmlogger]
C --> D[PCP Archive]
D --> E[历史数据回放]也就是说：
如果没有 pmlogger，就没有后面的历史数据回放。
安装PCP后，pmlogger默认会作为系统服务运行，配合pmcd采集指标。
1 | [root@localhost ~]# systemctl enable pmlogger --now |
默认的性能归档日志放在 /var/log/pcp/pmlogger/本机主机名/
1 | [root@localhost ~]# ls /var/log/pcp/pmlogger/$(hostname)/ |
一套完整PCP归档集由3个配套文件组成，三者必须放在一起，不能单独删除或修改其中任意一个：
20260927.11.01.0：核心性能数据主体文件20260927.11.01.index：索引文件，用于快速定位时间点20260927.11.01.meta：元信息文件，记录指标描述、单位等信息
Latest 是软链接，永远指向当前正在写入的归档集，方便直接调用。pmlogger.log 是pmlogger自身的运行日志，排查采集异常时查看。
pmval：查看具体性能指标
前面：
1 | [root@localhost ~]# pminfo |
负责解决：
“指标叫什么？”
而：
1 | [root@localhost ~]# pmval |
负责解决：
“这个指标现在是多少？”
实战举例
- 实时查看CPU空闲率
1 | [root@localhost localhost.localdomain]# pmval kernel.all.cpu.idle |
持续输出系统CPU空闲时间占比，对应top命令输出里的 id 字段。
- 实时查看CPU用户态占用
1 | [root@localhost localhost.localdomain]# pmval kernel.all.cpu.user |
这条命令持续输出用户态CPU时间，对应top里us字段。业务进程大量计算的时候，这个指标会明显上涨。
- 实时查看CPU内核态占用
1 |
|
对应top里sy，如果这个数值很高，说明大量消耗在内核系统调用、内核处理逻辑。
- 查看空闲内存指标
1 | [root@localhost localhost.localdomain]# pmval mem.util.free |
直接读取系统空闲内存，和free命令里的free字段对应。
- 查看磁盘读指标
1 | [root@localhost localhost.localdomain]# pmval disk.dev.read |
查看磁盘读请求，排查磁盘大量读IO场景，相当于iostat的读相关指标。
- 自定义采样间隔
pmval默认每秒输出一次。用-t参数设置采样间隔，单位秒。
1 | [root@localhost localhost.localdomain]# pmval -t 5 kernel.all.cpu.idle |
每5秒输出一次CPU空闲指标，适合长期观察缓慢变化的指标，减少屏幕刷屏。
实际工作中非常推荐大家养成一个习惯：
不知道指标叫什么，就先用 pminfo 找；找到之后，再用 pmval 看。
5. pmchart：图形化实时监控
PCP 自带一个轻量级图表工具 pmchart，可以把多个指标画成曲线图。，不过这个需要安装dnf install pcp-gui -y
`
比如同时监控：
1 | pmchart kernel.all.cpu.idle disk.dev.read network.interface.in.bytes |
你就可以直观看到：
- CPU 空闲率如何变化
- 磁盘读取是否有峰值
- 网络流量是否同步增长
这对于分析问题发生时的指标关联性非常有帮助。
实战提示：生产 Linux 服务器大多是最小化无图形部署，一般不会安装桌面环境，
pmchart更多是本地工作站调试使用，线上服务器优先用命令行工具。
PCP 与 sysstat 的区别
很多人会问：既然有了 sysstat，为什么还要用 PCP？
这里做一个简单对比：
| 维度 | sysstat | PCP |
|---|---|---|
| 定位 | 轻量性能工具包 | 完整性能监控框架 |
| 采集方式 | cron / systemd timer 调用 sa1/sadc | pmcd + pmlogger 统一采集 |
| 指标范围 | 系统、磁盘、网络、进程等基础指标 | 系统、容器、数据库、应用等多领域指标 |
| 历史数据 | sa 日志文件 | 归档日志仓库 |
| 可视化 | 弱，需二次导出 | 原生 pmchart，也可对接 Grafana |
| 分布式 | 较弱 | 支持多节点集中分析 |
| 适用场景 | 单机问题排查 | 复杂系统、集群、性能分析平台 |
总结一句话：
sysstat 适合快速排查单机问题，PCP 适合构建长期、统一、可回放的性能监控体系。
常用 PCP 命令实战
1. 实时查看 CPU 空闲率
1 | [root@localhost ~]# pmval kernel.all.cpu.idle |
输出会持续显示 CPU 空闲率变化。
2. 查看系统平均负载
1 | [root@localhost ~]# pmval kernel.all.load |
这里通常会看到 1 分钟、5 分钟、15 分钟负载。
3. 查看磁盘 IO 操作次数
1 | [root@localhost ~]# pmval disk.dev.read |
4. 查看网络接收流量
1 | [root@localhost ~]# pmval network.interface.in.bytes |
5. 查看内存可用空间
1 | [root@localhost ~]# pmval mem.physmem |
注意：不同版本的指标名称可能略有差异，可以使用 pminfo 查找。
PCP 历史数据回放
PCP 的真正威力在于历史数据回放。
如果 pmlogger 已经配置并运行，你就可以回放过去某个时间段的性能数据。
例如：
1 | [root@localhost ~]# pmval -a /var/log/pcp/pmlogger/localhost.localdomain/20260927.11.01 kernel.all.cpu.idle |
使用 Grafana 可视化 PCP 指标
PCP 本身已经具备不错的分析能力，但在企业环境中，更常见的做法是：
PCP 负责采集和存储，Grafana 负责统一展示。
通过 PCP 的 Grafana 数据源，你可以把历史指标展示成更美观的仪表盘，例如：
- CPU 使用率趋势
- 内存占用趋势
- 磁盘 IO 峰值
- 网络流量变化
- 系统负载曲线
- 容器资源开销
- NFS 延迟分析
这样，运维、开发、测试人员都可以通过浏览器查看系统历史状态，而不需要登录服务器敲命令。
我们可以把 PCP 和 Grafana 结合起来。整体架构就是：
flowchart LR
A[Linux服务器] --> B[PMDA]
B --> C[pmcd]
C --> D[pmlogger]
D --> E[PCP Archive]
C --> F[pmproxy]
E --> F
F --> G[Grafana]
G --> H[浏览器 Dashboard]PCP 负责性能数据体系。Grafana 负责可视化。两者结合以后，就可以通过浏览器统一查看性能指标。
想要让 Grafana 读取 PCP 的指标，有一步必不可少：在已经跑着 pmcd 的服务器上，把 pmproxy 服务启动并设置开机自启。
pmproxy 相当于一个代理。Grafana 没法直接连 pmcd，就靠 pmproxy 中转请求。默认情况下 pmproxy 会对外提供 REST API，访问地址 http://localhost:44322/metrics，Grafana 就是从这个地址拉取PCP指标。
实战举例
- 先启动 pmproxy 服务
在部署了 pmcd 的这台服务器执行下面命令，直接启动+设置开机自启：
1 | [root@localhost ~]# systemctl enable --now pmproxy |
这个服务默认监听 44322 端口。如果你的 Grafana 部署在别的机器，记得防火墙放开这个端口。好在 firewalld 自带 pmproxy 服务规则，不用手动敲端口号：
1 | [root@localhost ~]# firewall-cmd --add-service=pmproxy --permanent |
- 安装 Grafana 和 PCP 插件
grafana-pcp就是对接PCP的Grafana插件。在RHEL系统里，grafana 和 grafana-pcp 包都放在 AppStream 软件源，直接dnf安装就行：
1 | [root@localhost ~]# dnf install grafana grafana-pcp -y |
启动一下服务
1 | [root@localhost ~]# systemctl enable --now grafana-server |
1 | [root@localhost ~]# firewall-cmd --add-service=grafana --permanent |
打开浏览器，访问地址 http://ip:3000，就能进入 Grafana 的网页管理界面。
默认账号和密码都是 admin，直接用这套凭据登录就行。
这里要注意，第一次登录的时候，系统会强制要求你修改密码，按照页面提示设置新密码保存即可。
装好 grafana-pcp 软件包之后，PCP对应的数据源插件会自动安装好，不用我们手动上传插件文件。
接下来只需要在Grafana网页里把插件启用：
打开Grafana界面，点左上角菜单，依次进入 Administration › Plugins and data › Plugins。
在已安装插件列表里找到 Performance Co-Pilot，点进插件详情页，再点右上角的 Enable 按钮，插件就开启完成了。
进到Grafana网页界面，打开 Connections › Data Sources，点「Add new data source」新增数据源，在列表里找到 PCP Vector。
来到PCP数据源的配置页面，先给这个数据源起个名字，最重要的是URL这一栏，填部署了pmproxy那台服务器的地址。
简单测试环境的话，剩下所有选项都不用改动，保持默认就行。填完点 Save & Test，保存配置同时测试连通性，看到提示连接成功就代表没问题。
最后一步就是创建监控大盘。Grafana的仪表板有几种玩法：可以在网页里从头手动新建，也可以直接上传JSON文件导入，还能从Grafana公共仪表板库直接导入现成模板。
grafana-pcp插件页面自带了不少预制好的仪表板，拿来直接用很省事。切换到Dashboards标签，挑选符合你需求的PCP Vector仪表板打开就能用。
实战小例子
假设pmproxy跑在192.168.1.100这台机器，端口默认44322，URL就填写[http://192.168.1.100:44322](http://192.168.1.100:44322)。
点Save & Test，如果提示连接失败，优先排查两件事：第一，服务器上pmproxy服务有没有正常跑；第二，防火墙有没有放行44322端口。
前面咱们用 pmval、pcp dstat，只能在服务器命令行看文字，长时间看趋势特别不方便，翻历史数据更是麻烦。
把PCP接入Grafana之后，网页上直接出CPU、内存、磁盘、网络的曲线图，做成监控大盘。值班的时候不用一台台ssh登录服务器，打开网页就能看所有主机性能。再搭配pmlogger的归档功能，出问题之后直接拖动时间轴回看过去的曲线，找业务卡顿的时间点，排查起来省事很多。
补充小提示
Grafana 可以和PCP装在同一台机器，也可以单独部署。远程访问的时候，要保证Grafana服务器可以正常访问http://服务器IP:44322/metrics，防火墙、云服务器安全组都要记得放行44322端口。
总结：什么时候该用 PCP？
如果你只是想快速排查一台服务器为什么卡，sysstat 通常足够。
但在以下场景中，PCP 更合适：
- 需要长期保存详细历史性能数据
- 需要关联分析多个指标
- 需要统一监控系统、数据库、容器、网络等不同层次
- 多台服务器需要集中性能分析
- 希望对接 Grafana 做可视化展示
- 需要更灵活的指标扩展能力
对于中大型环境、集群环境、需要事后深度分析的场景，PCP 是非常值得投入学习的工具。
- 微信
- 支付宝
- Paypal Donate
