Swap占用高不等于内存不足，关键看available是否持续低于500MB、si/so是否持续大于100、是否存在VSZ远大于RSS的进程；需结合vm.swappiness配置与进程虚拟内存行为综合判断。
Swap 占用过高，不等于物理内存不够——它更可能是系统“主动换出”或程序“悄悄吃掉”的结果。关键不是看用了多少，而是看为什么用、谁在用、有没有必要用。
先看全局：确认 Swap 是否真告急
运行 free -h，重点盯两行：
-
Swap 行的 used 和 total：比如
Swap: 2.0G 1.8G 200M，说明已用 90%，需警惕；但若还有几百 MB 剩余，未必是瓶颈。 - Mem 行的 available：这个值代表当前可立即分配的内存。如果 available 还有 1G+，而 swap 已满，大概率是 swappiness 过高或进程异常，不是内存总量不足。
- 再补一句：vmstat 1 看
si（swap-in）和so（swap-out）是否持续非零。如果每秒都在进出几百 KB，说明系统正反复换页，I/O 已成拖累。
定位元凶：找出谁在大量使用 Swap
系统本身不记录“哪个进程占了多少 Swap”，但可通过 /proc 接口推算：
- 运行以下命令快速列出 Swap 使用最多的前 10 个进程：
- 重点关注输出中 Swap 占用远大于 RSS 的进程（比如 RSS 才 30MB，Swap 却有 500MB），这往往意味着该进程申请了大量虚拟内存但实际驻留少，内核把它“冷数据”换出去了。
- 常见嫌疑对象：Java 应用（-Xmx 设得过大）、宝塔 BT-Task、Python 脚本处理大文件、数据库临时排序区、tmpfs 挂载点下的大文件。
查配置与行为：判断是不是系统太“勤快”
Linux 默认 swappiness=60，意思是只要内存使用率达 40% 就开始考虑换出。对多数服务器来说偏激进：
- 查当前值：cat /proc/sys/vm/swappiness
- 临时调低（比如设为 10）：sudo sysctl vm.swappiness=10
- 永久生效：把
vm.swappiness=10加到 /etc/sysctl.conf 末尾，再执行 sudo sysctl -p - 注意：swappiness=0 并不完全禁用 swap（OOM 前仍会启用），只是大幅延迟；设为 1 是更稳妥的生产选择。
清理与验证：释放 Swap 并观察效果
确认问题进程后，可针对性处理；若只是临时压测导致，也可手动清空 Swap（需确保 available 充足）：
- 先关闭 swap：sudo swapoff -a
- 再重新启用：sudo swapon -a
- 此操作会把所有 swap 数据读回内存，所以务必确认 available ≥ swap used，否则可能触发 OOM。
- 操作后立刻用 free -h 和 vmstat 1 对比，看 si/so 是否归零、响应是否恢复。
