ki-pi很多刚开始接触 Linux 的朋友都有过这种经历：命令背了一堆，ls、cd、cp、mv 用得滚瓜烂熟，可真到了线上服务器上，遇到"机器负载突然飙高""某个服务莫名其妙起不来""远程连不上机器"这三类问题，还是不知道从哪下手。凑巧的是，这三类问题对应的正好是 Linux 运维里最基础也最高频的三项能力：负载监控、服务管理、SSH 工具使用。
我把它们放到一篇文章里讲，是因为在实际工作中这三件事从来不是割裂的。你几乎总是先通过 SSH 连上远程服务器，然后用各种工具观察系统负载，定位到服务异常之后，再用服务管理命令去处理，最后回到 SSH 查看结果。这就是一个完整的远程运维闭环。这篇文章适合刚入行的运维、经常和 Linux 服务器打交道的开发同学，以及自学 Linux 想系统性补基本功的人。我会按自己平时实际操作的顺序来讲，包括一些命令为什么这么选、哪些坑我踩过，尽量不写那些"看起来正确但实际用不上"的废话。
1. 负载监控：先把"负载高"三个字拆开看
1.1 load average 的三个数字，很多人其实没读懂
几乎每篇讲负载监控的文章，都会让你先敲一个命令：
bash复制$ uptime
10:35:22 up 3 days, 4:12, 2 users, load average: 0.82, 0.65, 0.43
load average 后面那三个数字，分别代表过去 1 分钟、5 分钟、15 分钟的系统平均负载。我第一次看到这个输出时以为 0.82 是个"负载百分比"，后来才发现完全不是一回事。
准确地说，load average 统计的是处于运行态和不可中断睡眠态的进程数量的时间平均值。通俗讲就是：这段时间里平均有多少个进程在排队等着系统给它们分配资源。这个资源可能是 CPU，也可能是磁盘 IO、锁等待等。所以看到 0.82 时，正确理解是"过去一段时间里平均有 0.82 个进程在排队"，而不是"系统负载用了 82%"。
判断负载是否异常，最常见的经验是拿负载值和 CPU 核心数对比。4 核的机器负载长期在 4 左右，基本说明 CPU 被排满；到 8 就意味着排队很严重了。但这个判断有个前提——负载高确实是由 CPU 造成的时候才成立。如果瓶颈在磁盘 IO 或者内存交换，这个对比就没那么直接。这也是我一再强调的原因：load average 只能当"报警器"，真正找问题必须往下一层扒。
再补充一点，很多人不知道 /proc/loadavg 这个文件：
bash复制$ cat /proc/loadavg
0.82 0.65 0.43 1/456 3210
前三个数跟 uptime 输出一致；第四列的分子是当前正在运行的进程数，分母是系统总进程数；第五列是最近创建进程的 PID。日常手动看负载用 uptime 就够，但如果你要写监控脚本、做告警采集，很多方案底层读的就是这个文件，知道格式会有帮助。
1.2 看负载的三件套：top、vmstat、iostat怎么配合
刚才说 load average 只是报警器，那真正的"显微镜"是什么？我日常最常用的三个命令是 top、vmstat、iostat，它们各管一段，配合起来基本能覆盖 90% 的负载排查场景。
top 是最直观的动态监控工具。进去之后重点看两个区域：顶部几行的系统汇总，包括 uptime、进程数、CPU 时间占比、内存占用；下面是按资源占用排序的进程列表。我实际排查时会这样操作：
- 按
P键按 CPU 占用排序，看谁在烧 CPU； - 按
M键按内存占用排序，看谁在吃内存； - 按数字
1展开每个 CPU 核心的使用率，判断是不是单核被打满； - 按
z开高亮，按x高亮当前排序列，方便盯关键进程。
top 里特别需要养成习惯看的一个字段是 %wa（IO wait），表示 CPU 等待磁盘 IO 完成的时间占比。这个值如果长期在 30% 以上，基本可以断定磁盘 IO 是当前瓶颈。这时候你死盯着 CPU 占用是找不到答案的，因为 CPU 可能在"干等"。
vmstat 是被很多人低估的命令，它用一行数字就能把系统整体状态说清楚：
bash复制$ vmstat 2 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
3 1 0 120000 30000 5200000 0 0 10 20 100 200 15 10 70 5 0
命令含义是每 2 秒采样一次，一共采样 5 次。我主要看这么几列：
r：运行队列中的进程数，长期大于 CPU 核数说明 CPU 不够用；b：不可中断睡眠状态的进程数，通常和磁盘 IO 强相关；si/so：swap 换入换出的量，持续非零说明内存吃紧，系统在频繁换页；bi/bo：块设备每秒读入/写出的块数，判断磁盘读写压力的直接指标；us/sy：用户态和系统态 CPU 占用，sy 长期超过 20% 就要留意是不是内核层面出问题；wa：CPU 等待 IO 的时间占比，这个数字高配合b列非零，基本坐实 IO 瓶颈。
iostat 则是在确认 IO 有问题之后做进一步细化的工具，能把每块磁盘、每个分区的情况列出来。重点看 %util 和 await。%util 表示磁盘在处理 IO 的时间占比，新手容易以为到 100% 才算满，但如果是 SSD，60% 以上就可能明显影响性能了，因为 SSD 的内部排队和延迟特性和机械盘完全不同。await 是每次 IO 请求的平均处理时间，机械盘正常应该在几毫秒到二十毫秒之间，如果飙到几百毫秒，这盘基本就是"废"了，该考虑换盘或者排查是什么进程在疯狂读写。