一、服务器慢/卡，先别急着重启
"网站突然变慢""SSH 敲命令很卡""CPU 飙高不下"，这是运维里最高频的诉求。很多人第一反应是重启，但重启只是掩盖问题，问题会反复出现。正确姿势是：现象 → 定位 → 归因 → 处置。Linux 自带一套强大的命令行性能观测工具，下面用一套"事件驱动"的思路，讲清楚如何用 top/vmstat/iostat/free/ss/pidstat 等命令一步步揪出瓶颈，而不是靠猜。
二、第一眼定级：uptime 与 top
先看系统负载和进程概貌：
uptime # 输出 1/5/15 分钟平均负载 Load Average top # 动态查看 CPU/内存/进程 ``` top - 10:20:01 up 12 days, 5:12, 2 users, load average: 3.61, 3.20, 2.80 Tasks: 210 total, 1 running ... %Cpu(s): 62.5 us, 30.0 sy, 7.5 ni, 0.0 id ... KiB Mem : 8169172 total, 1324000 free ... ```Load average 三个数的解读有个误区：它不代表禁用词"CPU 使用率"，而是"处于可运行或不可中断状态的进程数"。判断负载是否过高要结合 CPU 核数——8 核机器 load 4 很正常，2 核机器 load 4 就已饱和。top 里注意
us（用户态）、sy（内核态）、wa（I/O 等待），其中wa偏高往往指向磁盘或内存 Swap 问题。按 CPU 排序：进入 top 后按Shift+P；按内存排序按Shift+M；1查看每核使用率；x高亮当前排序列。三、细分 CPU 与进程：pidstat / mpstat
需要精确到每个进程或每个内核的 CPU 消耗时，用 sysstat 家族的 pidstat 和 mpstat（Debian/Ubuntu 装 sysstat）：
# 每个 CPU 的使用率（每秒刷新，共 3 次） mpstat -P ALL 1 3 # 每个进程的 CPU 与内存占比，每 1 秒采样 5 次 pidstat -u -r 1 5 # 看某个进程及其线程的 CPU pidstat -t -p PID 1 3如果 us 高，找 pidstat 里的高热进程，多半是业务代码死循环或计算密集任务；如果 sy 高，通常是频繁系统调用（如大量文件读写、上下文切换），配合
pidstat -w 1 5观察 cswch 上下文切换频率。四、内存与 Swap：free 的正确理解
Linux 内存使用率容易被 free 的显示误导，很多新手看到 "used 7G" 吓一跳，其实其中大部分是缓存（buff/cache）可回收。正确看内存：
free -h # 关键: Mem 行的 total/used/available；available 才是"还能用多少" # 以及 Swap 行是否压力大判断是否内存不足：看 available 长期告急，或 Swap 的 si/so 持续非零（说明在频繁换页）。用 vmstat 看整体：
vmstat 1 5 # procs 的 r(运行队列)/b(阻塞) # memory 的 si/so(swap in/out) # cpu 的 us/sy/wa/id若 r 远高于 CPU 核数 = CPU 饱和；若 b 或 wa 偏高 = 磁盘 I/O 瓶颈；si/so 非零 = 内存吃紧在换页。
r才是判断 CPU 是否忙的最关键指标。五、磁盘 I/O：iostat 与 df
网站卡顿除了 CPU 和内存，磁盘 I/O 也常被忽略。iostat 看设备负载、df 看容量：
df -h # 磁盘容量，别写到 100% iostat -x 1 3 # 磁盘详细 I/O：%util、await、svctm # %util 高说明设备繁忙；await 高说明排队等待久（可能是磁盘慢）数据库场景写多，I/O 瓶颈尤其常见。若 %util 持续很高但实际吞吐不大，可能是随机小 IO 太碎（如频繁 fsync 的小事务），可考虑把日志放 SSD 或调低 sync 频率。排查日志写入风暴也可用
iotop -P（需 root）直接看每个进程的磁盘读写速率。六、网络与连接数：ss 结合排查
连接数被打满、端口异常，用
ss（替代已被逐步淘汰的 netstat）：ss -tlnp # 所有监听端口的进程 ss -s # socket 汇总：TCP 连接状态计数 ss -tan state established | wc -l # 当前已建立连接数 ss -tan state time-wait | wc -l # TIME_WAIT 数TIME_WAIT 异常增多常见于高并发短连接场景，可通过开启 TCP time_wait 重用合理缓解；SYN 队列被打满则常是 SYN Flood 或服务线程不足。结合
netstat -s看 TCP 重传、丢包统计，能快速判断网络质量。若大量连接集中在某端口，再回头看该服务的并发处理能力。七、综合诊断：一次慢查询实战串联
把上面工具串起来，一次"网站突然变慢"的排查流程：
# 1. 看负载与整体 uptime; top -bn1 | head -20 # 2. 判断是 CPU / 内存 / IO vmstat 1 5 # 3. IO / 进程 深挖 iostat -x 1 3; pidstat -u 1 5 # 4. 若是 Web，结合 Nginx access 日志和数据库慢查询（前面文章已讲） tail -n 100 /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head最后根据归因下手：CPU 高→优化代码或加核；内存紧张→调 buffer/参数或升配；IO 高→换 SSD 或优化 SQL；连接多→调 max_connections。这套"先定级、再细分、后归因"的节奏，能让排查不再靠猜，快速收敛到真正的根因。
写在最后
性能监控不是把一堆命令背下来，而是建立一套"观察→假设→验证"的方法。核心抓手就三个：负载/运行的进程数量（top、vmstat 的 r）、内存可用量（free 的 available、vmstat 的 si/so）、磁盘与网络的忙闲（iostat 的 %util、ss 的 TCP 计数）。记住 free 高 used 要看 available、load 要跟核数比、wa 高指向 IO、r 高指向 CPU。能稳定地完成"定位-归因"，你才真正把服务器的健康状况握在了自己手里，而不是每次遇到问题只会按重启键。
