3、系统监控工具链：top/htop/atop的深度使用、vmstat与系统瓶颈定位、iostat与磁盘性能分析
各位同学，欢迎来到第三章。这一章我们聊聊监控工具链。
说实话，我刚入行那会儿，觉得监控就是敲个top看看CPU占用率。后来在车载项目上吃了大亏——系统莫名其妙卡顿，查了三天才发现是磁盘I/O在捣鬼。从那以后，我养成了一个习惯：监控不是看一个指标，而是看一组指标。
今天我们就来把这套工具链捋清楚。我会从最常用的top开始，逐步深入到vmstat和iostat。你想想看，如果连系统哪里堵了都不知道，还谈什么调优？
3.1 top：最基础的性能快照
top是Linux自带的进程监控工具。它就像一个实时更新的仪表盘，告诉你当前系统在忙什么。
我个人习惯，一上来先看load average。这玩意儿有三个数值：1分钟、5分钟、15分钟的平均负载。如果1分钟远高于15分钟，说明系统最近突然变忙了。
关键指标解读：
- %CPU：进程占用的CPU百分比。注意，多核下这个值可能超过100%。
- %MEM：进程占用的物理内存百分比。
- VIRT / RES / SHR：虚拟内存、常驻内存、共享内存。RES才是实际占用的物理内存。
- S：进程状态。R（运行）、S（睡眠）、D（不可中断睡眠，通常是I/O等待）。
嗯，这里要注意一个坑：top默认按CPU占用排序。但有时候CPU不高，系统却卡得要命。这时候你得按M键按内存排序，或者按P键切回CPU排序。我曾经在排查一个内存泄漏问题时，就是靠top按内存排序，发现一个进程的RES值在缓慢增长，最终定位到问题。
实用技巧：
在top界面按1，可以查看每个CPU核心的使用情况。车载系统通常是多核异构架构，看看是不是某个核心被某个进程占满了。
3.2 htop：top的增强版
htop是top的升级版，界面更友好，操作更直观。它支持鼠标操作，还能用颜色区分不同资源的使用情况。
我个人更喜欢htop，因为它能显示进程树。在车载系统中，很多进程是父子关系，比如systemd启动了一堆服务。用htop按F5键，一眼就能看出哪个子进程在吃资源。
htop的独特优势：
- 支持垂直和水平滚动，可以查看所有进程和完整命令行。
- 可以直接用F9发送信号（比如kill进程）。
- 可以自定义显示的列，比如加上
IO_RATE查看I/O速率。 - 颜色编码：CPU、内存、交换分区用不同颜色显示，一目了然。
不过要注意，htop默认不显示I/O信息。你需要按F2进入设置，在Display options里勾选Detailed CPU time和I/O activity。我在一次车载路测中，就是靠这个发现了一个日志进程在疯狂写盘，导致系统响应变慢。
3.3 atop：更强大的系统监控
atop是我在车载项目中用得最多的工具。它不仅能看当前状态，还能记录历史数据，方便事后分析。
atop的界面信息量很大。顶部是CPU、内存、磁盘、网络的整体情况，下面是每个进程的详细数据。我最看重的是DSK这一列，它显示进程的磁盘读写速率。
避坑指南：
我曾经在调试一个车载娱乐系统时，发现atop显示的磁盘I/O很高，但top却看不出问题。后来才发现，atop默认会记录所有进程的I/O，而top需要额外配置才能显示。所以，排查I/O问题时，优先用atop。
atop还有一个杀手锏：按d键可以按磁盘I/O排序，按m键按内存排序，按c键按CPU排序。这样你就能快速定位到罪魁祸首。
实用命令：
# 启动atop，每5秒刷新一次
atop -i 5
# 查看历史记录（默认保存在/var/log/atop/）
atop -r /var/log/atop/atop_20240101
# 在atop界面中，按'g'显示通用信息，按'p'显示进程信息3.4 vmstat：系统瓶颈定位利器
vmstat是一个轻量级的系统监控工具。它不像top那样花哨，但信息密度极高。说白了，它就是系统性能的X光机。
我一般这样用：
# 每2秒输出一次，共输出5次
vmstat 2 5输出结果中，我重点关注这几列：
| 列名 | 含义 | 警戒线 |
|---|---|---|
| r | 运行队列中的进程数 | 超过CPU核心数，说明CPU饱和 |
| b | 不可中断睡眠的进程数（I/O等待） | 持续大于0，说明磁盘I/O是瓶颈 |
| swpd | 已使用的交换空间 | 持续增长，说明内存不足 |
| si / so | 从磁盘交换入/出的内存量 | 大于0，说明内存严重不足 |
| us / sy / id / wa | 用户态/内核态/空闲/I/O等待的CPU时间占比 | wa > 30% 说明I/O是瓶颈 |
嗯，这里有个经验之谈：如果r列的值持续大于CPU核心数，但us和sy都不高，那多半是锁竞争或者上下文切换太频繁。我在一个多线程的音视频处理项目中就遇到过这种情况，最后通过减少锁粒度解决了问题。
瓶颈定位三步法：
- 看CPU：
us高说明用户态程序吃CPU，sy高说明系统调用频繁。 - 看内存：
swpd和si/so高说明内存不足，需要加内存或优化内存使用。 - 看I/O：
b列和wa高说明磁盘I/O是瓶颈。
3.5 iostat：磁盘性能分析专家
如果说vmstat是X光机，那iostat就是磁盘的CT扫描仪。它能精确告诉你每块磁盘的读写性能。
我最常用的命令：
# 每2秒输出一次磁盘统计信息
iostat -x 2
# 只看某个磁盘（比如sda）
iostat -x sda 2输出结果中，这些指标是关键：
| 指标 | 含义 | 说明 |
|---|---|---|
| %util | 磁盘忙闲程度 | 接近100%说明磁盘饱和 |
| r/s / w/s | 每秒读/写请求数 | 结合队列长度看 |
| rkB/s / wkB/s | 每秒读/写的数据量 | 看吞吐量是否达到磁盘极限 |
| await | 平均I/O响应时间（毫秒） | 超过10ms说明性能下降 |
| svctm | 平均I/O服务时间 | 接近await说明队列不深 |
| aqu-sz | 平均队列长度 | 持续大于1说明磁盘忙 |
避坑指南：
我曾经在分析一个车载导航系统的磁盘性能时，发现%util只有60%，但系统响应很慢。后来仔细看await，发现高达50ms。这说明磁盘本身性能差（可能是eMMC老化），而不是负载高。所以，不要只看%util，要结合await一起看。
另外，iostat还能看CPU的I/O等待时间。在输出结果的最上面，有一行CPU信息，其中的iowait就是I/O等待占比。如果这个值高，说明CPU在等磁盘，系统整体性能受限于I/O。
实战经验：
在车载系统中，eMMC和UFS是常见的存储介质。它们的随机读写性能远低于顺序读写。如果你发现await很高，但rkB/s不高，那多半是随机读写太多。这时候可以考虑用fio工具测试一下磁盘的极限性能，看看是不是硬件瓶颈。
3.6 工具链组合使用
说了这么多，这些工具怎么配合使用呢？我总结了一个套路：
- 先用
top或htop扫一眼：看看哪个进程在吃资源，系统负载高不高。 - 再用
vmstat定位瓶颈类型：是CPU、内存还是I/O？ - 最后用
iostat或atop深挖：如果是I/O瓶颈，就看具体是哪个磁盘、哪个进程在读写。
举个例子。有一次车载系统在启动时特别慢。我先用top看到wa很高，然后用vmstat确认b列持续大于0，最后用iostat -x发现sda的%util接近100%，await高达80ms。进一步用atop按I/O排序，发现是一个日志服务在疯狂写日志。优化了日志写入策略后，启动时间从30秒降到了10秒。
嗯，这就是工具链的价值。单独用任何一个工具，都只能看到冰山一角。组合起来，才能看到全貌。
总结一下：
top/htop：快速查看进程和系统概览。atop：更详细的进程I/O和历史记录。vmstat：定位CPU、内存、I/O瓶颈。iostat：深入分析磁盘性能。
下一章，我们会深入perf和ftrace，看看怎么分析CPU内部的性能问题。到时候你会发现，这些工具只是开始。