Linux 性能监控与调优：快速判断 CPU、内存、磁盘谁成了瓶颈

服务器变慢时，新手最容易乱猜："是不是 CPU 不够？""加内存？"结果钱花了问题还在。性能优化的第一步永远是"先测量、再下手"——你得先知道瓶颈到底在 CPU、内存、磁盘还是网络，才能对症下药。这篇文章先纠正一个普遍误解（负载均值≠CPU 使用率），再给你一套从总览到细分的分析工具链，让你几分钟内锁定真正的瓶颈。

一、负载均值不是 CPU 使用率

uptime 末尾那三个数字（1/5/15 分钟）叫负载均值，它是"可运行进程数 + 不可中断进程数（通常是等 IO）的指数滑动平均"，不是 CPU 占用百分比。关键对照是核数：负载约等于核数表示饱和，单核理想低于 1，4 核理想低于 4。超过就开始排队。最容易被忽略的是：IO 等待（wa）也会推高负载，但此时 CPU 可能是空闲的——所以"负载高"不等于"CPU 忙"，可能是磁盘卡住了。看负载要结合核数一起看，才有意义。

uptime
w

二、总览：top / htop 看进程

top 是实时进程视图，按 CPU 或内存排序（top 里按 P 或 M）能立刻看到谁是资源大户。htop 是它的优化版，支持鼠标、颜色、树状视图，可读性更好。但别只盯 %CPU 瞬时值——采样太短有噪声，要结合 vmstat/sar 看趋势。top 还能看整体负载、运行/睡眠进程数、内存概况，是排查的第一现场。

top
htop

三、内存：free 与 /proc/meminfo

看到内存 used 很高就以为不够？这是最大误区。Linux 会拿空闲内存做缓存（cache/buffer）加速文件读写，这部分在需要时会立刻释放。你要看的是 available（可用），不是 free。free -h 以人类可读单位显示；更细的看 /proc/meminfo。如果 available 持续很低、并开始用 swap（si/so 非零），那才是真内存紧张，该加内存或查内存泄漏的进程了。

free -h
cat /proc/meminfo

四、磁盘容量：df / du

磁盘满也会导致各种诡异故障。df -h 看各挂载点用了多少；du -sh 看某个目录占多大，定位"空间去哪了"。注意 df 看的是文件系统层面，删了大文件但进程还占着句柄时，df 可能不降——这时要重启相关进程或 lsof 找泄漏的 fd。容量和 IO 是两回事：满盘是空间问题，%util 100% 是速度问题。

df -h
du -sh /var/*

五、系统级统计：vmstat / iostat / sar

这三个来自 sysstat 包，是定位瓶颈的利器。vmstat 1 每秒刷新，看 r（可运行进程）、b（不可中断）、us/sy/id/wa（CPU 各态）、si/so（swap）。iostat -xz 1 看磁盘 %util（利用率，接近 100% 即饱和）、await（平均等待毫秒，越高越卡）。sar 能看历史：sar -u CPU、sar -r 内存、sar -d 磁盘。装 sysstat 后这些才可用，别忘装。

sudo apt install sysstat
vmstat 1
iostat -xz 1
sar -u 1 3

六、进程级 IO：iotop

怀疑是磁盘 IO 瓶颈，但不知道谁在狂写？iotop 实时按 IO 排序进程，一眼看出是哪个服务在刷盘。它需要 root，且部分内核要开 TASK_DELAY_ACCT 支持。配合 iostat 的 %util，你就能确认"是磁盘满了"还是"某个进程在作妖"，从而决定是换盘、限流还是修应用。

sudo iotop

七、sysctl 基础调优

确认瓶颈后，轻度调优可用 sysctl。常见如降低 vm.swappiness（默认 60 偏积极换页，设 10–30 让系统更愿留 cache）、调大 fs.file-max（提高文件句柄上限）、开 net.ipv4.tcp_tw_reuse（加快端口回收）。但 sysctl -w 只是临时生效，必须写进 /etc/sysctl.d/ 再 sysctl --system 持久化，否则重启即丢。调优是锦上添花，先解决真实的瓶颈进程才是根本。

sysctl vm.swappiness
sudo sysctl -w vm.swappiness=10
echo 'vm.swappiness=10' | sudo tee /etc/sysctl.d/99-swappiness.conf
sudo sysctl --system

八、常见误判

把负载高当 CPU 满（其实是 IO 等）；只看 free 不看 available；凭 top 瞬时值下结论；盲目把 swappiness 调到 0（反而易 OOM）；忘记装 sysstat 导致 iostat/sar 不可用；调 sysctl 不持久化。避开这些，你的性能分析才靠谱。记住一句话：没有测量，就没有优化。

补充与延伸：性能分析是一种思维方式

工具一大堆，但比工具更重要的是方法。性能问题九成九是"木桶短板"：要么 CPU 满、要么 IO 等、要么内存被吃光、要么网络卡。正确姿势是先找到那块最短的板，再针对它下手，而不是凭感觉乱调参数。所以排查永远从"全局概览"开始——uptime 看负载、free 看内存、iostat 看磁盘、top 看谁在吃资源，先定位大类，再逐层下钻。没有这一步，你改的 sysctl 可能根本没碰到点子上，只是自我安慰。

另一个关键思维是"建立基线，关注变化"。一台机器平时负载 0.5，今天突然 5，才是异常；如果它一直就 5，那是它的常态。所以初接手一台机器，先跑一轮把各项指标记下来当基线，以后波动才有参照。很多"我怀疑它慢"的模糊抱怨，落到数字上要么根本没慢，要么能精确定位到某个时间点（比如每晚备份时 IO 飙高）。数据化你的直觉，运维才从玄学变科学。

最后提醒：优化要克制。Linux 默认参数已经是内核团队为全球海量场景调过的均衡值，盲目改 swappiness、调 TCP 缓冲区，常常带来你测不出的副作用。真正有效的优化往往不是调内核，而是应用层：加索引、加缓存、少查一次数据库、关掉没用的后台进程。先把能白嫖的软件层收益吃完，实在到天花板了再动系统。记住：能不调就不调，要调先测再调，调完还要能回滚。

还有一个常被低估的杠杆：关掉没用的东西。很多 VPS 默认装了一堆你根本不用的服务（蓝牙、打印、快照 agent），它们占内存也扩大攻击面。systemctl disable 掉用不到的，用 ps 和 systemd-analyze blame 找出拖慢启动的元凶，机器立刻轻快。性能优化的第一课，往往不是"加"，而是"减"。

补充一个快速定位 CPU 问题的套路：top 里按 1 展开所有核心，看是单核被打满还是整体均衡；再按 P 按 CPU 排序，抓出最吃的进程；如果是某个 Java/Python 服务，进一步用它自带的诊断（如 jstack、py-spy）看是哪个函数。别一看到 load 高就 reboot，先把"是谁、为什么"问清楚，reboot 只是把问题暂时藏起来，下次它还会以同样的姿势回来。

再说内存：很多人一看 free 里 Mem 的 used 很高就慌，其实 Linux 会把空闲内存拿去做磁盘缓存（buff/cache），这部分在需要时会被回收，不是真的被用掉。真正要看的是 available 列——它表示"不 swap 就能立刻拿来用的内存"。只要 available 还充裕、si/so（swap 进出）长期为 0，内存就没什么压力。读懂这一列，你就不会被"内存快满了"的假象骗去乱调参数。

性能排查是一门越练越顺的手艺。刚开始你可能面对一堆数字发懵，但每次你顺着"负载→内存→IO→进程"这条线把一个问题查到底、并验证了自己的假设，你的直觉就长一分。久了你会发现，大部分"慢"都不是玄学，而是某个明确的瓶颈在喊话。带着测量的习惯去面对每一台机器，你离"稳"也就更近一步。

临了给个心态：性能优化永远服务于业务目标，不是为了把数字跑漂亮。用户要的是"打开快、不卡顿"，对应的可能是首屏时间、接口延迟这些指标，而不是抽象的 load 值。先把业务关心的那几个指标盯住，再用本文的工具去拆它，你的优化才会落在用户能感知的地方，而不是自我感动的图表上。

记住，测量先于优化，业务先于数字。带着这两句去面对任何一台变慢的机器，你都不会再盲目。本文的工具，就是帮你把"感觉慢"变成"知道哪里慢"的桥。