服务器变慢的主观与客观：先量化再动手

「服务器变慢」这四个字本身不是数据。用户说慢、老板说慢、自己打开也觉得慢，但慢了多少、从什么时候开始、是全部页面还是个别接口，没有这些量化，后面的动作都是凭感觉。 一、先把"慢"翻译成数字 最直接的量化是响应时间。对重点页面或接口各取一条 URL，循环取样： for i in $(seq 1 20); do curl -o /dev/null -s -w "%{time_total}\n" https://www.example.com/api/list; sleep 1; done 得到 20 个耗时样本，取中位数比看单次更有意义。再把口径拆开：DNS 解析、建连、首字节各占多少，用 -w 模板里的 time_namelookup、time_connect、time_starttransfer 分别观察，一眼能看出时间花在哪一段。测量的口径也要固定：测哪条 URL、几点测、取样多少次，写进记录里，数据才有可比性。取样时段也要错开备份和定时任务的窗口，别把噪音测进去。 二、和资源水位对上号 拿到响应时间，再上服务器核对资源。uptime 输出的负载除以 CPU 核数，长期大于 1 说明算力不够；vmstat 1 5 里 r 列持续大于核数是 CPU 在排队，b 列偏大是阻塞在 IO；iostat -x 1 里 %util 接近 100% 说明磁盘忙不过来。响应时间和某项资源同时劣化，因果链才算成立。这些命令看的是当下，别忘了对照变更记录：变慢常与发布、配置改动同步出现，把慢的起始时间和最近一次发布的时间对一对，很多时候答案就在那里。 三、和用户感知对齐 "变慢"要拆开问。是所有用户都慢，还是个别地区？是突然变慢，还是随数据量增长逐渐变慢？所有用户同时变慢，优先查服务器和链路；个别地区慢，多半是线路问题；逐渐变慢，常见原因是数据量上来之后 SQL 和索引欠了账。这几个问题问清楚，排查方向至少砍掉一半。还有一种情况要单独分出来：用户说的是点按钮没反应，那要区分是接口慢还是前端脚本卡，浏览器开发者工具的 Network 面板能看到每个请求的耗时，别把前端的账记到服务器头上。 建议每周固定测一次这组数字并存档，这就是基线。没有基线，"变慢"永远只是一句感觉；有了基线，变没变、变多少，一目了然。