服务器Swap策略调整

Swap空间并不是“内存不够时的救命稻草”，这种认知偏差往往导致服务器在关键时刻卡死。Swap策略调整的核心，不是简单地增大或禁用Swap，而是控制内核的swappiness参数与内存回收水位，让系统在内存压力和I/O延迟之间找到最优平衡点。很多运维人员发现服务器负载飙升、应用响应变慢，第一反应是加内存，但实际上，只要把默认的swappiness从60调整到10，就能让数据库服务延迟降低30%以上。问题的根源在于，Linux内核默认倾向于将不常用的匿名页交换出去以腾出文件缓存，这在桌面场景合理，但在服务器场景往往是灾难。

要调整策略，必须先理解内核是怎么决定换出内存的。Linux内核将物理内存分为匿名页和文件页。匿名页是进程动态分配的内存，没有对应的磁盘文件，比如堆栈数据；文件页是磁盘文件的缓存，比如日志、数据库数据文件。当系统需要分配新内存时，内核会回收最不活跃的页面。如果swappiness值较高，内核会优先换出匿名页到Swap，保留文件页缓存。如果swappiness较低，内核会优先丢弃文件页缓存，尽量保留匿名页在物理内存中。对于运行数据库、消息队列这类自身管理缓存的服务器，文件页缓存的价值远低于进程自身的堆内存，所以必须降低swappiness，让内核不要轻易把进程内存换出去。

swappiness的取值范围是0到100，默认60。这个值并不是Swap使用量的绝对值，而是一个权重比值，表示内核在回收内存时，回收匿名页相对于回收文件页的倾向程度。设置为0并不意味着完全禁用Swap，而是告诉内核尽可能不换出匿名页，除非系统内存已经极度紧张。设置为100则意味着匿名页和文件页被回收的权重相同。对于MySQL、PostgreSQL这类数据库服务器，建议将swappiness设置为1，而不是0。因为内核版本在3.5之后，设置为0会触发一种特殊行为，内核会完全避免换出匿名页直到文件页缓存几乎被清空，这可能导致文件页缓存被过度回收，造成磁盘I/O突然飙升。设置为1既能保持极低的换出倾向，又保留了内核在极端情况下的灵活性。调整命令很简单：

sysctl vm.swappiness=1

永久生效需要写入配置文件：

echo "vm.swappiness=1" >> /etc/sysctl.conf

只调整swappiness还不够，另一个关键参数是vm.vfs_cache_pressure，它控制内核回收dentry和inode缓存的倾向程度。默认值是100，值越高，内核越积极地回收这些缓存。对于文件操作频繁的服务器，比如文件存储、静态资源服务，适当降低这个值可以提升文件系统性能。但如果服务器内存压力大，可以适当调高，让内核更快释放这些缓存。对于数据库服务器，建议设置为50到70之间，这样既能保留足够的文件系统元数据缓存，又不会因为缓存过多而挤占进程内存。调整命令：

sysctl vm.vfs_cache_pressure=50

内核的内存回收行为由三个水位线控制：min、low、high。当可用内存低于low水位线时，内核开始异步回收内存；低于min水位线时，进程会阻塞等待内存回收。这些水位线通常由内核根据内存大小自动计算，但在高负载服务器上，默认的水位线可能导致内存回收启动过晚，造成瞬间卡顿。可以通过vm.min_free_kbytes参数手动设置最小空闲内存，这个值直接影响min水位线。对于内存较大的服务器，适当增大这个值可以让内核更早开始回收内存，避免突然的内存压力。比如一台64GB内存的数据库服务器，可以将min_free_kbytes设置为262144，即256MB。这样内核会在空闲内存低于这个阈值时就开始回收，而不是等到内存几乎耗尽才行动。

sysctl vm.min_free_kbytes=262144

但要注意，设置过大反而浪费内存，因为这部分内存平时不会被分配给进程使用。一般建议设置为物理内存的0.1%到0.4%之间。

在多路服务器上，NUMA架构会带来额外的Swap策略问题。每个NUMA节点有自己的内存和Swap区域，如果进程在一个节点上分配内存，但Swap空间在另一个节点的磁盘上，就会产生跨节点I/O，性能大幅下降。更严重的是，如果某个NUMA节点的内存耗尽，内核可能会大量换出该节点上的进程内存，即使其他节点还有空闲内存。这种情况在数据库服务器上尤为常见，因为数据库进程通常绑定在特定CPU核心上，内存分配集中在某个NUMA节点。解决方法是设置vm.zone_reclaim_mode参数。设置为0表示允许跨节点内存分配，尽量避免Swap；设置为1表示优先在本地节点回收内存，可能导致Swap。对于数据库服务器，建议设置为0：

sysctl vm.zone_reclaim_mode=0

同时，可以通过numactl命令查看每个节点的内存使用情况，确认是否存在不均衡。

Swap策略调整不只是内核参数，Swap设备本身的配置同样关键。很多云服务器的Swap设备是虚拟磁盘，I/O性能远低于物理SSD。如果Swap设备性能差，一旦发生换出，应用响应时间会从毫秒级飙升到秒级。优先选择NVMe SSD作为Swap设备，避免使用HDD。如果服务器有多个磁盘，可以将Swap空间分散到不同磁盘上，设置相同的优先级，让内核以轮询方式使用，提升Swap I/O的并行度。优先级设置示例：

# 在/etc/fstab中配置多个Swap分区
/dev/nvme0n1p2 none swap sw,pri=10 0 0
/dev/nvme1n1p2 none swap sw,pri=10 0 0

相同优先级意味着内核会并行使用它们，类似RAID 0的效果。另外，Swap空间的大小不是越大越好。传统建议是物理内存的1到2倍，但这是针对小内存时代的规则。对于256GB以上内存的服务器，如果swappiness已经调低，Swap空间只需要8GB到32GB即可，主要用于应对极端情况，而不是作为日常内存扩展。

在容器化和虚拟化环境中，cgroup的内存限制会与Swap策略产生复杂交互。如果cgroup设置了memory.limit_in_bytes，当容器内进程达到这个限制时，内核会开始回收容器内的内存。如果同时配置了memory.memsw.limit_in_bytes，这个值包含了物理内存和Swap的总和。很多容器平台默认不限制Swap使用，导致容器在内存压力下大量使用Swap，而宿主机的swappiness设置对容器内的内存回收行为影响有限。正确的做法是，在容器配置中明确设置memory.swappiness，覆盖宿主机的全局设置。对于关键业务容器，可以设置为0或1，确保容器内进程不会使用Swap。在Kubernetes中，可以通过设置memory limits和requests来控制，但底层仍然依赖cgroup的swappiness参数。

调整完策略后，必须通过监控验证效果。vmstat命令可以实时查看si和so列，分别表示每秒换入和换出的内存量。如果so持续大于0，说明系统仍在频繁换出，需要进一步降低swappiness或检查内存泄漏。更精确的监控可以通过/proc/vmstat文件中的pswpin和pswpout计数器，计算一段时间内的增量，判断Swap活动的真实频率。另外，sar -S命令可以查看Swap使用率的历史数据。如果Swap使用率在调整后仍然缓慢增长，说明存在内存泄漏或某些进程的内存分配模式需要单独优化。对于Java应用，可以通过JVM参数-XX:+AlwaysPreTouch预分配物理内存，避免运行时动态换出。

某些场景需要完全不同的Swap策略。比如日志分析服务器运行Elasticsearch，JVM堆内存已经通过-Xmx锁定，但堆外内存和文件缓存竞争激烈。这类服务建议完全禁用Swap，因为Elasticsearch依赖文件系统缓存来加速搜索，一旦发生Swap，搜索延迟会急剧恶化。禁用Swap的命令：

swapoff -a

并从/etc/fstab中注释掉Swap条目。但禁用Swap后，必须确保物理内存足够容纳所有进程的常驻内存，否则会触发OOM Killer随机杀死进程。另一个极端场景是内存超卖的虚拟化宿主机，需要开启Swap并适当调高swappiness，利用Swap来平滑内存压力，避免虚拟机被强制关机。这种情况下，Swap设备必须使用高性能SSD，并且配置swap文件而非swap分区，方便动态调整大小。

不同内核版本对swappiness的处理存在细微差异。内核4.0之前，swappiness=0的行为是尽量不换出匿名页；

4.0到5.0之间，swappiness=0完全禁止换出匿名页，直到文件页缓存耗尽；

5.0之后又恢复了类似早期的行为。因此，在调整之前，务必确认当前内核版本，避免策略与预期不符。长期维护中，每次内核升级后都应重新验证Swap行为。可以通过编写简单的测试脚本，模拟内存压力并观察Swap活动，确保策略仍然有效。另外，systemd管理的系统可能通过systemd的MemorySwapMax参数覆盖全局Swap设置，需要检查服务单元文件中的相关配置。

Swap策略调整不是一次性操作，而是需要根据业务负载、内存使用模式、内核版本持续迭代的过程。核心思路始终是：让内核在正确的时机回收正确的内存，用最小的I/O代价换取最大的内存利用效率。