htop 入门：在云服务器上看懂 CPU、内存和进程谁在吃资源

云服务器变慢时，先观察资源与进程的关系，比立即结束进程更稳妥。htop 提供交互式的整体资源和进程视图，适合在终端里寻找线索，但它展示的是采样快照，不是故障根因分析器。下面以读取信息为主，不把某个颜色或一次尖峰当作结论。

一、先看整体，再选进程

在已安装 htop 的 Linux 主机上运行下面的命令。不同发行版、版本和个人配置可能改变布局及快捷键提示，应以界面底部帮助为准。

htop

上方通常显示各逻辑处理器、内存、交换空间和负载信息，下方列出进程。先连续观察几次刷新，判断是整机资源紧张，还是单个任务短暂繁忙。若只有一个核心很忙，其他核心空闲，整体平均利用率可能掩盖单线程瓶颈。

按 P 可切到 CPU 排序，按 M 可切到内存排序，也可用 F6 选择排序列。F3 用于搜索，F4 用于过滤，F5 切换树状视图，F1 查看帮助。过滤只改变展示内容，不会暂停或结束被隐藏的进程。

二、把几个关键列读准确

PID 标识进程，USER 表示所属用户，CPU% 表示采样期间的处理器占用，TIME+ 是累计处理器时间，二者不能互相替代。运行很久的后台进程可能累计时间很长，却并非当前最忙的对象。

RES 是驻留物理内存，VIRT 是虚拟地址空间，不能把 VIRT 直接当成实际吃掉的内存。共享内存会出现在多个进程的读数中，因此简单相加所有 RES 也未必等于整机内存消耗。

下面是人为构造的读数示意，不是某台服务器的实测输出，列也经过简化。

PID   USER   CPU%   RES    COMMAND
1234  app    180.0  320M   worker
5678  app      2.0  900M   api

在常见的按单核百分比展示方式下，多线程进程可能超过百分之百；这不等于整台主机已经超过容量。第二行常驻内存较大也不能直接证明泄漏，还要看负载、运行时间及后续变化。

三、区分忙碌、等待与内存压力

负载平均值不是 CPU 利用率，它还可能受到不可中断等待任务的影响。负载高而 CPU 不忙时，应继续检查磁盘等等待因素，不能仅凭进程排序认定计算能力不足。

Linux 会使用内存做缓存，空闲内存少不一定危险。结合可用内存、交换活动和业务延迟判断，比盯着颜色条更可靠。交换空间里已有数据也不等于此刻仍在频繁换页；需要持续观察，必要时再配合其他只读监控工具。

四、保留线索，不急于发信号

先记下异常进程的 PID、用户、命令和出现时间，再与业务流量或应用日志关联。树状视图有助于理解父子关系，但看到多个子进程并不意味着异常，进程池本来就可能如此工作。

F9 是发送信号入口，不是普通查看功能。误操作可能中断请求或造成数据损失；服务进程还可能被管理器自动拉起。没有确认影响范围和处置权限时，保持只读观察即可。

最后，把“哪个资源紧张、哪些进程相关、持续多久”分别记录下来。若要判断一天内的趋势，应依赖持续监控，而不是把一次终端截图当成全天表现。htop 最有用的作用，是帮助缩小下一步调查范围。