swap 到底该开多大
有台 1G 内存的小机器，跑几个常驻服务，隔三差五卡住。登上去看，free 显示内存还剩几十兆，swap 一千兆用满，负载却不高。
第一反应是加 swap。后来发现加完之后该卡还是卡，只是卡得晚一点。
先看是谁在用
把每个进程的 VmRSS 和 VmSwap 拉出来排个序，问题就露出来了：一个跑了两天多的进程，RSS 只有七十兆，swap 占了四百兆。它早就不干活了，但一直挂着，页面被换出之后再也不回来。
这种进程不会自己退出，也不会被 OOM killer 选中——内核觉得它"活着"，只是慢。它占着 swap，把真正需要换出的页面挤到磁盘上，于是整个系统进入一种低效的循环：读写磁盘越来越频繁，真正在跑的进程拿不到内存。
swap 不是内存的延伸，它是给"暂时不用但以后可能还要"的页面一个落脚点。常年不用的进程待在那里，等于把仓库当成了办公室。
几个数字
查了一下内核参数，vm.swappiness 是默认的 60。对桌面系统合适，对这种小服务器偏激进。调到 10 之后，内存压力下的换出行为明显收敛，但代价是内存真不够时会更早触发 OOM。
这其实是个取舍：要么让系统慢，要么让某个进程死。我倾向于后者——至少死得干脆，日志里能看到是谁。
结论
swap 开 1 到 2 倍物理内存对普通服务够用，关键不在大小，在于：
一是别让长命空闲进程一直挂着，能设超时就设超时；二是 swappiness 按用途调，别用默认值糊弄；三是监控 swap 的使用量而不是只看剩余内存，swap 快满的时候系统往往还没报警。
最后那台机器加到了 2G，swap 没动。原来的问题本质上不是内存不足，是没人管那些挂着不动的进程。