性能瓶颈分析：CPU负载、内存、I/O与网络延迟
大家好，我是老张。今天咱们聊聊性能瓶颈分析。说实话，这活儿看着简单，做起来门道不少。很多刚入行的朋友一上来就盯着CPU使用率看，其实这是个误区。我见过太多系统，CPU才跑30%，但业务就是卡得要命——问题出在别处。
性能分析，说白了就是找短板。你想想看，一个自控系统就像一条流水线，哪个环节最慢，整个系统就得等它。咱们今天就把CPU、内存、I/O、网络这四个维度挨个捋一遍。
一、CPU负载分析
CPU负载高，不一定就是坏事。我习惯先看负载曲线，而不是瞬时值。为什么？因为瞬时值会骗人。比如一个周期任务每100ms跑一次，你采样刚好落在空闲期，那CPU看起来就很低。
核心指标：
- CPU使用率：用户态+系统态+等待I/O
- 运行队列长度：Linux下看 /proc/loadavg，超过CPU核心数*0.7就要警惕
- 上下文切换：每秒切换次数，过高说明锁竞争或线程太多
我在项目中遇到过一件事。有个PLC上位机系统，CPU使用率才40%，但操作响应特别慢。一查，发现运行队列长度到了12，而CPU只有4核。说白了，就是任务太多，CPU在排队。后来把一些非实时任务绑到特定核心上，问题就解决了。
我的小技巧：用 top 命令时，按 '1' 看每个核心的负载。如果某个核心跑满，其他核心空闲，那就是单线程瓶颈。这时候加CPU核心数没用，得优化代码。
二、内存使用分析
内存问题比CPU隐蔽。我见过最坑的一次，系统跑了三个月突然崩溃，查下来是内存泄漏。嗯，这里要注意，自控系统通常7x24小时运行，内存泄漏是致命伤。
分析内存，我主要看三点：
- 物理内存使用率：别只看free命令，要看available。Linux会把空闲内存拿来做缓存，free显示很少，但available够用就行。
- Swap使用情况：一旦开始用swap，性能就崩了。我建议自控系统直接关掉swap，或者设得很小。
- 进程内存分布：用
pmap -x PID看每个进程的内存映射，找异常增长。
避坑指南：我曾经在DCS系统上遇到内存碎片问题。系统总内存还有30%空闲，但申请一块64KB的连续内存就是失败。原因是频繁分配释放小对象，导致内存碎片化。后来改用内存池，问题解决。
给大家一个实用命令：
# 查看内存占用前10的进程
ps aux --sort=-%mem | head -10
# 查看内存映射详情
cat /proc/$(pidof your_process)/smaps | grep -i pss三、I/O瓶颈诊断
I/O瓶颈是自控系统里最常见的性能杀手。为什么？因为现场数据要写盘、要读历史库、要记录日志。我见过一个SCADA系统，操作员点一下按钮，等5秒才有反应——查下来是历史数据写入把磁盘I/O占满了。
诊断I/O，我习惯用 iostat -x 1 看这几个指标：
| 指标 | 正常范围 | 异常信号 |
|---|---|---|
| %util | < 70% | 接近100%说明磁盘饱和 |
| await | < 10ms (SSD) | > 30ms 说明有排队 |
| svctm | < 5ms | 过高说明磁盘硬件有问题 |
| r/s + w/s | 看磁盘规格 | 超过IOPS上限就是瓶颈 |
重点：%util 到100%不代表磁盘坏了，只说明它忙不过来。但如果你看到 await 很高而 %util 不高，那可能是磁盘队列太深，或者有坏道。
我记得有一次，现场工程师说系统每隔半小时卡一次。我远程一看，iostat 显示每半小时有一次写峰值，IOPS冲到5000+。查下来是历史数据归档任务和报表生成任务撞在一起了。调整了调度时间，问题解决。
四、网络延迟分析
网络延迟在分布式自控系统里特别要命。一个控制指令从操作站到现场设备，中间经过交换机、网关、PLC，每一跳都有延迟。加起来可能就超时了。
我分析网络延迟的步骤：
- 基础延迟测试：用 ping 看RTT，正常局域网应 < 1ms。超过5ms就要查了。
- 丢包率：ping -f 看丢包，自控系统要求丢包率 < 0.1%。
- 带宽利用率：用 iftop 或 nload 看实时流量，别超过链路带宽的70%。
- TCP重传率：用 netstat -s 看重传段数量，重传率高说明网络不稳定。
一个实用技巧：用 mtr 命令代替 ping，它能显示每一跳的延迟和丢包。我在排查一个跨厂区网络问题时，就是靠 mtr 发现中间有一台交换机的光模块坏了。
你想想看，一个控制周期是100ms，如果网络延迟占了20ms，那留给计算和I/O的时间就只剩80ms了。所以网络延迟必须控制在周期时间的10%以内，这是我的经验值。
知识体系总览
下面这张图是我自己总结的性能瓶颈分析框架，大家可以参考：
这张图把四个维度的关键指标都列出来了。实际排查时，我建议按这个顺序来：先看CPU有没有异常，再看内存够不够，然后查I/O是不是瓶颈，最后看网络。为什么这个顺序？因为CPU和内存问题影响面最广，I/O和网络问题通常更局部。
总结一句话：性能瓶颈分析不是看单一指标，而是综合判断。CPU高不一定有问题，I/O低也不代表没事。关键是要理解你的系统在干什么，正常时的基线是什么。没有基线，就谈不上异常。
好了，这一章就聊到这儿。下一章咱们会讲具体的性能监控工具和实战案例，到时候我会拿几个真实项目来拆解。
公众号:蓝海资料掘金营，微信deep3321