Swap 频繁触发未必是内存不足，而是内存调度或应用异常的预警；需依次检查全局水位、定位高 swap 进程、分析内核内存健康指标，并通过调低 swappiness 和 drop_caches 临时验证根因。
Swap 频繁触发，不等于内存真不够——它更像系统发出的“预警信号”，提示内存调度策略或应用行为出了偏差。关键不是立刻清 swap，而是搞清：是物理内存真的吃紧？还是内核太积极换出？又或是某个进程在悄悄泄漏？下面分三步直击根因。
看全局水位：free -h + swapon --show 一起跑
单独看 free -h 容易误判。必须搭配 swapon --show 或 cat /proc/swaps，确认 swap 是否真在活跃使用（而非仅存在）。重点关注三个字段：
- available：真实可用内存，比 used/total 更可靠；如果它还有 1G+，swap 却在涨，说明不是缺内存，而是策略或进程问题
-
Swap used：持续增长 ≠ 紧急，但若伴随
si/so（swap-in/swap-out）值在vmstat 1中频繁跳动，就是颠簸（thrashing）已发生 -
swappiness 当前值：用
cat /proc/sys/vm/swappiness查；60 是默认，>30 就可能过早启用 swap，尤其当 available 还剩 20% 以上时
揪具体进程：找真正占 swap 的“元凶”
top 或 htop 默认不显示 swap 占用，得靠底层数据。运行这个命令快速排序 top 10：
sudo sh -c 'for i in /proc/[0-9]*; do pid=${i##*/}; awk -v p="$pid" "/VmSwap:/ {swap+=\$2} END {if(swap>0) print p, swap \" KB\"}" $i/status 2>/dev/null; done | sort -k2nr | head -n 10'
结果中注意两点：
- VSZ（虚拟内存）很大但 RSS（常驻内存）很小，而 Swap 占用高 → 很可能是该进程分配了大量内存却长期不用，被内核换出（如 Java 堆未 GC、Python 大对象缓存）
- PID 对应的命令（用
ps -p PID -o cmd=查）是否为已知服务（如宝塔 BT-Task、Java 应用、数据库 worker）；非预期进程要优先排查
查内核倾向与内存健康度
swappiness 只是开关，背后还有内存压力指标。运行：
cat /proc/meminfo | grep -E "^(MemAvailable|SwapCached|SReclaimable|PageTables)"
辅助判断：
- SwapCached > 50MB：说明刚换入的数据又被标记可换出，典型颠簸征兆
- SReclaimable 高 + MemAvailable 持续下降：page cache 被过度保留，挤压应用空间，内核被迫换出冷页
- PageTables 占用突增：进程创建大量小内存页（如 fork 频繁、线程数暴增），导致页表膨胀，间接推高 swap 使用
临时验证与收敛方向
确认问题后，别急着改配置。先做两件事：
- 临时调低 swappiness：
sudo sysctl vm.swappiness=10，观察 5 分钟内 swap 是否停止增长 - 对可疑进程尝试轻量级释放：
sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'（仅清 page cache/buffer，不影响进程） - 若 swap 不降反升，且对应进程 RSS 稳定但 Swap 持续涨 → 极大概率是该进程内存泄漏，需检查日志或重启服务
