swap空间是否成为性能瓶颈，关键看vmstat中si/so是否持续＞100kb/s、iostat中swap设备await＞50ms且%util接近100%、free中available是否远低于内存总量；高used但available充足属历史冷数据，可安全清理，否则强行清swap会触发oom或加剧卡顿。
Swap 空间本身不会“不足”，真正的问题是 Swap 被高频使用，说明物理内存已持续承压，系统被迫频繁换入换出页面，引发 I/O 瓶颈和响应延迟。排查的关键不是看 Swap 容量是否“满”，而是确认它是否正在成为性能瓶颈。
确认 Swap 是否正在拖慢系统
先观察实时交换活动，而非只看 used 值：
- 运行
vmstat 1，重点关注 si（swap-in，单位 KB/s）和 so（swap-out）两列：若两者持续 >100 KB/s，尤其 so 高且 si 同步上升，说明系统在反复搬运数据，已进入交换颠簸（thrashing）状态； - 配合
iostat -x 1查看磁盘 %util 和 await：如果 swap 所在设备（如/dev/sda2）await 显著升高（>50ms）、%util 接近 100%，基本可锁定 I/O 是卡点； - 检查
free -h中的 available 值：若远低于物理内存总量（例如 8GB 内存仅剩 200MB available），即使 Swap used 不高，也意味着内核已在积极回收内存，Swap 很可能即将被大量启用。
定位具体占用 Swap 的进程
系统不会告诉你哪个进程“用了 Swap”，但可以查出哪些进程的匿名页被换出了：
- 用以下命令列出按 Swap 使用量排序的前 10 个进程（需 root）：
- 重点关注 VSZ（虚拟内存大小）远大于 RSS（实际驻留内存）的进程，比如 VSZ=2GB、RSS=150MB，差值部分很可能已落入 Swap；
- 常见嫌疑对象：Java 应用（堆设置过大但实际活跃数据少）、Python 后台任务（如宝塔 BT-Task）、未限制内存的容器、长期运行的脚本服务。
区分真实内存压力与“假性 Swap 占用”
Swap used 高 ≠ 当前有性能问题，必须结合内存余量判断：
- 如果
free -h显示 available 内存充足（例如 > 总内存的 20%），而 Swap used 仍很高，大概率是历史高峰遗留的“冷数据”未被换回——此时清 Swap 是安全的，且能释放磁盘空间； - 如果 available 很低、si/so 持续活跃、磁盘 await 高，说明物理内存确实不够，强行清 Swap（如
swapoff -a）会立刻触发 OOM Killer 或导致更严重卡顿； - 注意 swappiness 值：默认 60，若设为 1–10 可显著抑制 Swap 使用，适合内存充裕的服务器；但设为 0 并不禁止 Swap（仅禁用匿名页换出），休眠和 OOM 保护仍依赖它。
快速验证与临时缓解
在确认内存余量充足的前提下，可尝试温和释放：
- 执行
sudo sysctl vm.drop_caches=3清空 page cache 和 slab，间接减少内存压力，有时能促使内核将部分 Swap 数据换回（非强制）； - 若确定要清空 Swap，先确保
free -h中 available > Swap used，再执行：sudo swapoff -a && sudo swapon -a（适用于单 Swap 设备）；
或针对具体设备：sudo swapoff /dev/sda2 && sudo swapon /dev/sda2； - 操作后立即用
vmstat 1观察 si/so 是否归零、系统响应是否恢复。
