2. RMC核心指标解读：CPU利用率、内存带宽、磁盘IOPS、网络吞吐量、延迟与抖动

各位同学，咱们直接切入正题。RMC性能监控，说白了就是盯着几个关键数字，看系统到底累不累、哪里卡。

我个人习惯，拿到一个系统，先看这六个指标：CPU利用率、内存带宽、磁盘IOPS、网络吞吐量、延迟、抖动。这六个指标，就像人的体温、血压、心率，缺一不可。

2.1 CPU利用率：别被100%骗了

CPU利用率，大家最熟悉。但你真的看懂了吗？

我见过太多人，一看CPU 100%就慌了。其实，CPU 100%分两种：

• 用户态高（us）： 应用程序在干活，比如跑模型、做计算。这通常是好事。
• 系统态高（sy）： 内核在忙，比如中断处理、锁竞争。这往往是坏事。

我曾经遇到一个案例，CPU利用率只有30%，但业务响应慢得像蜗牛。查了半天，发现是上下文切换太高，每秒几十万次。CPU都在忙着切换进程，根本没空干活。

# 查看CPU各项指标
mpstat -P ALL 1 5

# 重点关注：
# %usr - 用户态
# %sys - 系统态
# %iowait - IO等待
# %idle - 空闲

2.2 内存带宽：比容量更隐蔽的瓶颈

内存带宽，很多人会忽略。你想想看，内存容量够用，但带宽不够，数据一样传不过来。

RMC场景下，尤其是深度学习推理，内存带宽往往是第一瓶颈。模型参数、中间结果，都在内存里搬来搬去。

我记得有一次，帮客户调优一个图像识别服务。CPU利用率不高，内存也够，但就是慢。用 perf 一测，发现缓存未命中率高达40%。说白了，CPU大部分时间都在等内存数据。

怎么测？用 stream 基准测试，或者直接用 numactl --hardware 看内存布局。

# 查看NUMA节点和内存带宽
numactl --hardware

# 用stream测试内存带宽
stream_c.exe

2.3 磁盘IOPS：别让硬盘拖后腿

磁盘IOPS，就是每秒能读写多少次。对于数据库、日志系统，这个指标至关重要。

嗯，这里要注意：IOPS和吞吐量是两码事。IOPS看的是次数，吞吐量看的是大小。小文件读写，IOPS更重要；大文件读写，吞吐量更重要。

我调过一个日志采集系统，磁盘利用率才30%，但IOPS已经飙到上限了。原因是日志文件太小，每次写入都要刷盘，导致大量随机写。

# 查看磁盘IOPS
iostat -x 1

# 重点关注：
# r/s - 每秒读次数
# w/s - 每秒写次数
# await - IO等待时间（毫秒）

2.4 网络吞吐量：带宽够用吗？

网络吞吐量，就是单位时间内能传多少数据。RMC场景下，模型分发、结果回传，都依赖网络。

说白了，网络吞吐量受限于两个因素：带宽和协议效率。千兆网卡理论125MB/s，实际能跑满80%就算不错了。

我遇到过最坑的事：客户说网络带宽是万兆，结果实际吞吐量只有200MB/s。查了半天，发现是网卡驱动没装对，或者交换机端口协商成了千兆。

# 服务端
iperf3 -s

# 客户端
iperf3 -c 服务器IP -t 30 -P 4

2.5 延迟与抖动：用户体验的杀手

延迟，就是发一个请求到收到响应的时间。抖动，就是延迟的波动幅度。

你想想看，如果延迟稳定在10ms，用户觉得还行。但如果有时1ms，有时100ms，用户就会觉得卡顿。这就是抖动在作怪。

我记得调优一个实时语音识别服务，平均延迟只有50ms，但用户反馈经常断断续续。用 ping 和 mtr 一测，发现网络抖动高达200ms。原来是某个交换机在做流控。

# 测试网络延迟和抖动
ping -c 100 目标IP

# 重点关注：
# min/avg/max/mdev - 最小/平均/最大/标准差
# mdev就是抖动

2.6 六个指标的关系：一张图看懂

这六个指标不是孤立的。CPU高可能导致内存带宽吃紧，磁盘IOPS高会拉高CPU的iowait，网络抖动会影响整体延迟。

下面这张图，是我自己总结的RMC核心指标关系图。你看一眼就明白了。

2.7 实战：如何快速定位瓶颈

说了这么多，到底怎么用？我分享一个实战套路。

1. 先看CPU： 如果us高，说明应用在忙，好事。如果sy高，查上下文切换和锁。
2. 再看内存带宽： 用 perf stat 看缓存未命中率，超过20%就要优化数据布局。
3. 然后看磁盘： 用 iostat 看await，超过10ms说明磁盘扛不住了。
4. 接着看网络： 用 iperf3 测实际吞吐量，对比理论值。
5. 最后看延迟和抖动： 用 ping 和业务日志，看P99延迟。

好了，这六个指标，你心里有数了吧？下次遇到性能问题，别慌，按这个顺序查一遍，基本能定位个七七八八。