SSH 连得上、命令不返回：先读 /proc/pressure/io，再决定是走是留

先确认卡的是磁盘，不是网络

SSH 能连上、命令却半天不返回，连读一遍日志都跑不完——这种"活着但动不了"的状态，八成不是网络问题。先花一分钟把现象分开：SSH 会话本身通着，就说明链路没事；uptime 里看看负载是不是有一大截卡在不可中断等待；iostat -x 1 看 %util 和 await 有没有贴顶；dmesg -T | tail 看块设备有没有报错。

读一眼 /proc/pressure/io

现在主流内核都在 /proc/pressure/ 下导出三份压力数据，io 就是磁盘这份，直接 cat 就行：

some avg10=0.00 avg60=0.00 avg300=0.00 total=0
full  avg10=0.00 avg60=0.00 avg300=0.00 total=0

内核文档对这两行的解释很关键：some 是"至少有一个任务被这个资源卡住"的时间占比，full 是"所有非空闲任务同时被卡住"的时间占比。文档对 full 的说法相当重——这种状态下 CPU 周期是真的在空转，长时间处在 full 里的负载就是在 thrashing。所以 some 高而 full 低时，你的程序还在干活；full 一起冲到九成，那就是整台机器在干等磁盘，跟你的代码没关系。

avg10、avg60、avg300 是最近 10 秒、60 秒、300 秒三个窗口，正好用来回答商家最爱问的那句"什么时候开始的"；total 是累计停顿微秒数，适合抓那种一闪而过的尖峰。

留住现场，再开工单

最常犯的错是上来就重装。重装会把证据一起抹掉，而且如果问题在宿主侧，装完过两天还是一样。开工单前先攒四样东西：

• 间隔几分钟取三次 /proc/pressure/io 的输出，能看出是持续还是阵发；
• ps -eo stat,pid,comm,wchan:30 | grep '^D' 抓卡在不可中断状态的进程，ext4 的日志线程 jbd2 出现在这里，问题基本就落在磁盘后端；
• 十秒钟的 iostat -x 1 片段；
• 具体时间点，带上时区。

工单别写"机器很慢"。写成这样更有分量：某日某时起，/proc/pressure/io 的 full avg10 到九成，jbd2 线程处于 D 状态，读日志目录超过十秒没返回，根分区占用不到一成。这种工单商家没法用一句"重启试试"糊过去。顺手把两件事说在前面：请检查宿主侧的虚拟磁盘后端；如果要迁移或重装，先问我，别直接动数据。

什么时候别修了

三件事凑齐就该走：退款窗口还开着、数据在你自己手里另有一份、工单里始终没人说清宿主机到底怎么了。便宜 VPS 最贵的成本从来不是那几美元，是你耗在上面等一个解释的那一周。机器修好了照样值得留，但前提是先有退路。