第3章 健康检查工具 - 基础命令
做运维这些年，我见过太多人一上来就抓瞎——服务器卡了，先重启再说。其实不用这样。系统把它的状态都写在/proc里了，只是需要正确的工具去读。
今天咱们就把最常用的几个命令捋一遍。top、htop、vmstat、iostat、netstat、ss。这些都是吃饭的家伙，必须得熟。
3.1 top —— 第一眼印象
top是我登录任何服务器后敲的第一个命令。说白了，它就是系统的「健康码」——扫一眼就知道整体状态好不好。
top - 09:34:21 up 120 days, 3:15, 2 users, load average: 0.08, 0.12, 0.10
Tasks: 186 total, 1 running, 185 sleeping, 0 stopped, 0 zombie
%Cpu(s): 2.3 us, 0.7 sy, 0.0 ni, 96.7 id, 0.3 wa, 0.0 hi, 0.0 si
MiB Mem : 7978.1 total, 1234.5 free, 3045.6 used, 3698.0 buff/cache
MiB Swap: 2048.0 total, 1798.2 free, 249.8 used. 4478.1 avail Mem关键指标速读
- load average：三个数分别对应1、5、15分钟的平均负载。超过CPU核数就要警惕了。
- wa：iowait，这货高了说明磁盘是瓶颈。我在一个数据库项目里见过wa飙到60%，后来发现是慢盘在作祟。
- id：空闲率。低于20%说明CPU已经吃紧了。
我的习惯：top跑起来后，按1展开每个CPU核心，看是不是负载不均。很多程序是多线程的，但只有一个核跑满——这就是典型的「锁竞争」信号。
3.2 htop —— top的现代版
htop不是所有系统都自带的。但我建议你装一个。为什么？因为它能让你用鼠标操作，点一下就能排序、杀进程。操作体验好太多了。
# Ubuntu/Debian
sudo apt install htop
# CentOS/RHEL
sudo yum install htop # 需要先启用EPEL源htop比top多了几个实用功能：树形视图（F5）、进程过滤（F4）、颜色高亮。我个人特别喜欢它的内存和CPU条状图，一眼就能看出资源消耗趋势。
注意：线上环境如果没装htop，别手忙脚乱去装包。先拿top顶着，这是基本功。我曾经在客户现场因为没装htop慌了神，后来想想纯属多余——top完全够用。
3.3 vmstat —— 系统瓶颈的放大镜
vmstat是用来定位瓶颈的，不是只看一眼就完事的。它的精髓在于连续采样。
# 每1秒采样一次，共5次
vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
1 0 249800 1234500 23800 3698000 0 0 12 15 1023 2034 12 4 83 1 0
0 0 249800 1234500 23800 3698000 0 0 0 2 985 1987 11 3 86 0 0重点看两列：r（运行队列）和b（阻塞队列）。r持续大于CPU核数，说明CPU不够。b大于0且持续上升，那八成是磁盘或锁在拖后腿。
我的小技巧：vmstat采样10次，观察si/so这两列。只要有非零值，说明物理内存不够了，在大量使用交换分区。这个时候加内存比调优管用得多。
3.4 iostat —— 磁盘的体检报告
iostat是专门看磁盘的。遇到I/O相关的告警，我第一个想到的就是它。
# 显示所有设备的详细统计，每2秒刷新一次
iostat -x 2
Device r/s w/s rkB/s wkB/s await svctm %util
sda 12.5 8.3 512.0 332.0 15.2 2.1 4.5
sdb 0.3 0.1 12.0 4.0 3.8 1.2 0.1| 指标 | 含义 | 警戒线 |
|---|---|---|
| %util | 磁盘繁忙百分比 | > 80% 说明磁盘已饱和 |
| await | I/O请求的平均等待时间（毫秒） | > 30ms 说明有较严重延迟 |
| svctm | I/O服务的实际处理时间 | 与 await 差距过大说明排队严重 |
| r/s, w/s | 每秒读写请求数 | 视磁盘类型而定 |
避坑指南：我曾经在监控系统里看到%util只有20%，但业务响应很慢。后来发现是SATA盘的队列深度太浅，请求都在排队。所以只盯着%util看是不够的，一定要结合await和svctm一起分析。
3.5 netstat vs ss —— 网络连接排查
这两个工具都是看网络连接的。但ss比netstat快得多，尤其是在连接数几万个的时候。
# 查看所有TCP监听端口
netstat -tlnp
ss -tlnp
# 查看连接统计摘要
netstat -s
ss -s说实在的，现代Linux上netstat已经不推荐用了。它读取的是/proc/net/tcp，而ss直接读取内核socket信息。生产环境里netstat跑一次可能要几秒，ss几乎是瞬间出结果。
我的经验：排查端口冲突或连接泄漏时，重点看两个状态——TIME_WAIT和CLOSE_WAIT。
- TIME_WAIT多一般是短连接没用好，调整net.ipv4.tcp_tw_reuse可以缓解。
- CLOSE_WAIT多说明代码里漏掉了close()调用，得找开发修。
# 统计各种状态的数量
ss -s
Total: 682 (kernel 1023)
TCP: 234 (established 187, closed 12, orphaned 1, synrecv 0, timewait 8, listen 26)3.6 工具选择——什么时候用哪个？
| 场景 | 首选工具 | 补充说明 |
|---|---|---|
| 快速看整体状态 | top / htop | htop更直观，但top几乎无处不在 |
| CPU跑满排查 | top + vmstat | vmstat的r列最有说服力 |
| 内存泄漏怀疑 | vmstat + free | vmstat看si/so，free看实际使用 |
| 磁盘I/O慢 | iostat -x | 重点关注await和%util |
| 端口/连接排查 | ss（优先） | netstat只在无法安装工具时用 |
思路总结：遇到性能问题，我的排查链条是：top看全局 -> vmstat看方向 -> iostat或ss定位到具体设备。先宏观后微观，别一头扎进细节里。
这些命令看着简单，但用熟了就是一把瑞士军刀。多接几次线上故障，你自然就记住了。嗯，先练起来吧。