凌晨跑批时，MySQL 的 P99 从 5 毫秒冲到 1 秒，磁盘利用率却不高，慢日志只写“等待资源”。free 内存仅剩数百 MB，监控同时出现 si、so 和 PSI 告警。拖慢请求的不是 SQL 突变，而是 Linux 内存回收、换页 I/O 与数据库等待叠加。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：ufovps（海外服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
直接回收为何能把毫秒延迟推成秒级
Linux 将空闲内存用于文件缓存。内存紧张时，kswapd 可后台执行页回收，优先清理干净缓存页，为新分配腾出空间。这个过程通常可以慢慢完成，不应直接命中每个数据库请求。
若分配线程必须立即拿到页面，就会进入直接回收，在关键路径同步扫描、淘汰页面。数据库 Buffer Pool 很大，清理脏页和等待回写会占用 CPU 与 I/O 队列；原本很快的分配因此变成毫秒到秒级等待。
匿名页不能直接丢弃，只能写入交换区。线程栈、排序缓冲被换出后，再次访问还要换入；页面反复换入换出，就形成交换抖动。脏页回写会放大延迟。缓冲池频繁清理后命中率下降，查询转而读盘，5 毫秒的操作因此拖到 1 秒。
直接回收不等于 swap。容器数据库还受 cgroup 限额约束：宿主机 free 内存很多，memory.high 仍可能迫使进程同步回收，memory.max 还可能触发 OOM。判断根因不能只看剩余内存，要看压力是否与业务停顿同时发生。
用 PSI、回收速率和交换活动锁定卡顿
先看 /proc/pressure/memory：some 表示部分任务因内存停顿，full 表示所有非空闲任务曾同时停顿；avg10、avg60、avg300 反映压力趋势。将其与数据库 P99 对齐，持续 some 多半拖慢局部请求，full 更接近整机停顿。PSI 能确认是否因内存堵住，却不能指出具体线程。
再从 /proc/vmstat 取 pgscan、pgsteal 的时间差，计算扫描与回收速率。pgscan 增长说明反复扫描，pgsteal 明显偏小说明页面难回收；累计值不能直接比较。再核对 vmstat 的 si、so、bi、bo 与 iostat 的 await，区分直接回收、换页和磁盘拥塞。
判断交换抖动不能只看 swap used。历史占用不等于正在抖动，应看 si、so 速率是否与延迟尖峰同周期。major fault 也可能来自文件页重新映射。ServLlama 可把 PSI、回收、I/O 和进程指标放在同一时间线，再与慢日志、锁等待交叉验证。
还要避开三个误区：free 低可能只是缓存多；PSI 为零可能漏掉短尖峰；容器环境须核对 memory.events 的 high、max、oom、oom_kill 计数。若回收速率高，但 PSI、si、so 和 P99 互不相关，这次回收更可能是背景噪声。
直接回收与交换抖动：为什么数据库会突然“卡住”
当分配线程拿不到空闲页，回收会在分配路径上同步发生，这就是直接回收。它让查询、日志写入或检查点线程亲自等待，普通 INSERT 也可能被拖成秒级延迟。后台页回收若赶不上分配速度，系统会把匿名页频繁换出又换入，形成交换抖动。数据库脏页还需写回，回收线程、checkpoint、WAL 刷盘争抢同一 I/O 通道，影响便不只来自内存。
交换抖动最隐蔽的表现是 CPU 不忙，数据库延迟却持续上升。不要只看 swap 使用量，必须结合 si/so 进出速率；冷进程占用 swap 并不等于正在抖动。PSI压力更适合判断任务是否因内存停顿：/proc/pressure/memory 中 some 表示部分任务被拖住，full 表示几乎所有非空闲任务都被拖住。PSI 高而 CPU、磁盘看似空闲，更能解释卡顿。
常见误区与落地检查清单
排查时不要把 free 低等同于故障，也不要因 swap 使用率高就禁用 swap；前者可能只是缓存，后者可能只是历史换出。容器还要核对 cgroup 的 memory.max、memory.high、memory.events，宿主机 PSI 未必反映限额。重启数据库、清缓存或盲目增大缓冲池，可能带来冷启动、checkpoint 甚至 OOM 风险。
可按顺序执行：①高峰采集 /proc/pressure/memory、/proc/vmstat、vmstat 1，并用 iostat、pidstat 记录 I/O 与进程等待；②对照数据库等待事件、慢日志、checkpoint 和刷盘延迟，确认尖峰是否与回收重叠；③检查 si/so、脏页比例、写回队列和 cgroup 事件，区分直接回收、后台回收与交换抖动；④先降并发或批大小，再在预算内调整缓冲池，并用 memory.high 渐进限流；⑤每次只改一个参数，观察 p99、吞吐、PSI 和 OOM 计数后再扩大变更。保留时间戳，才能证明修复来自哪一步。
最终目标不是让 free 看起来更多，而是在内存紧张时仍让数据库线程稳定完成关键 I/O。先用指标定位，再用限并发、缩小工作集和合理内存边界，把抖动挡在高峰之前。
喜欢 
顶
难过
囧
围观
无聊
