性能观测四件套：top、free、iostat、ss 联动读数

top：CPU 与进程（第 10 篇的深化）

$ top        # M 按内存排 / P 按CPU排 / 1 展开每核
load average: 6.80, 3.10, 1.20     ← 1分钟在飙，5/15分钟正常 = 刚发生的事
%Cpu(s): 85.0 us,  2.0 sy,  0.0 ni, 3.0 id,  9.5 wa
                                              ↑ wa 高 = CPU 在等磁盘

读表要点：三个 load 一起看走向（1 分钟高、15 分钟低 = 刚冒头；三个都高 = 持续过载）；us 高查应用，wa 高查磁盘——这两句能省一半排查时间。

free：别再被「内存所剩无几」骗了

$ free -h
       total   used   free   buff/cache  available
Mem:   7.8Gi  6.2Gi  120Mi  1.5Gi       1.1Gi
Swap:  2.0Gi    0B   2.0Gi

两句话纠正最大误区：free 小不是问题，Linux 把闲内存拿去做文件缓存（buff/cache）提高性能，要用时随时归还；真正该看的是 available——它才是「还能给新程序用多少」。available 持续很低、Swap 开始被用（used > 0），才是真内存告急。Java 应用还要叠加 JVM 视角（堆内堆外，JVM 系列讲过）。

iostat：磁盘到底忙不忙

$ iostat -x 1        # 每秒刷新一次（sysstat 包，yum install sysstat）
Device   r/s   w/s   rkB/s   wkB/s  await  %util
vda      2.0  180.0  64.0  51200.0   45.2   96.5
                                            ↑     ↑
                                   平均等待ms  磁盘饱和度

两个指标定生死：%util 长期 90%+ = 磁盘打满；await 飙升（正常几毫秒，异常几十上百毫秒）= I/O 变慢，上层表现就是接口卡顿。结合 top 的 wa 高，磁盘瓶颈基本实锤——再翻磁盘篇找是谁在狂写。

ss：连接数与端口

$ ss -s                      # 全局汇总（总连接、各状态计数）
$ ss -ant | awk 'NR>1{print $1}' | sort | uniq -c    # 状态分布
    120 ESTAB                ← 正常业务连接
   2500 TIME-WAIT            ← 短连接太多（客户端没复用连接池）
    300 CLOSE-WAIT           ← 应用没关连接（代码泄漏，值得警觉）
$ ss -ltnp                   # 谁在监听哪个端口（排「端口被占用」）

读数要点：TIME-WAIT 大多无害（网络系列讲过，主动关闭方的正常余韵）；CLOSE-WAIT 堆积是真病——对端关了你没关，基本是代码里连接没释放，必须修。网络细节在「网络基础硬核系列」已专篇展开，这里只留联动判断。

四表联动的判断矩阵

下一篇是系列收官：服务器排障手册——把 20 篇的命令串成五大事故场景的标准动作，一张清单带走。