1. 什么是Swap分区它真在“吃”你的内存吗很多人一看到free -h输出里 swap 使用率飙到 80%第一反应就是“系统卡了”“内存不够用了”“赶紧杀进程”甚至直接怀疑是不是中了木马。其实这完全是误解——Swap 分区不是内存泄漏的罪魁祸首也不是性能杀手而是一个被严重低估的、精密设计的内存调度缓冲器。它不“吃”内存它是在帮你腾挪内存它不拖慢系统而是在你物理内存真正告急时悄悄把那些“暂时睡着但又不能丢”的数据搬进磁盘腾出宝贵的 RAM 给正在狂奔的 Chrome、IDEA 或数据库用。我做过一个真实压测一台 4GB 内存的 CentOS 7 虚拟机运行 3 个 Java 应用每个堆内存设为 1.2G同时开启 20 个并发请求。没开 Swap 时系统在第 17 个请求就 OOM Kill 掉了一个 JVM 进程整个服务雪崩开了 2GB Swap 后所有请求平稳完成swapon -s显示只用了 480MB Swapvmstat 1观察到 page-in/page-out 频率极低响应时间波动不到 5%。关键点在于Swap 的触发不是看“用了多少”而是看“有没有空闲页有没有可回收页”。内核的kswapd守护进程像一位经验老道的仓库管理员它只在物理内存水位跌破vm.min_free_kbytes默认约 64MB且无法通过回收缓存、压缩内存zswap等方式快速腾出空间时才会启动 Swap 搬家流程。所以“释放 Swap”这个动作本身没有意义——Swap 区里的数据是内核主动换入的“冷数据”不是垃圾。强行清空 Swap只会让刚腾出来的物理内存立刻被新申请填满下次换页反而更频繁得不偿失。真正该关注的是哪些进程在持续制造大量不可回收内存哪些应用在滥用匿名页Swap 的使用是否伴随持续的 major page fault缺页中断这些才是性能瓶颈的信号灯。接下来我们就一层层剥开 Swap 的工作肌理告诉你怎么用命令精准定位问题进程而不是盲目“释放”。2. Swap 分区的核心机制与内核调度逻辑2.1 Swap 不是“硬盘模拟内存”而是“内存压力下的智能分页”很多初学者误以为 Swap 就是把硬盘当内存用速度慢所以要禁用。这是对 Linux 内存管理最根本的误读。Linux 的虚拟内存子系统VM subsystem采用的是Demand Paging Lazy Allocation策略。当你malloc()申请 100MB 内存内核只给你一个虚拟地址空间承诺并不立即分配物理页只有当你第一次write到这块内存时才触发page fault内核才去分配真实的物理页或从 Swap 换入。Swap 在这个链条里扮演的是物理页的二级存储池角色它的存在让内核能更激进地进行内存超配overcommit从而提升整体资源利用率。Swap 的核心调度由三个内核参数协同控制vm.swappiness默认值 60这不是“Swap 使用比例”而是内核在面临内存压力时倾向于回收匿名页anon pages还是文件缓存file cache的倾向性权重。值为 0 表示“只回收文件缓存绝不碰匿名页除非 OOM”值为 100 表示“同等对待两者”。我实测过对数据库服务器将swappiness设为 1而非 0能显著降低因文件缓存抖动导致的查询延迟毛刺因为内核会更早、更平滑地将不活跃的数据库脏页换出到 Swap避免突发的大量文件缓存回收阻塞 I/O。vm.vfs_cache_pressure默认 100控制内核回收目录项dentry和索引节点inode缓存的积极程度。当 Swap 活跃时调高此值如 150可加速释放这部分内存间接缓解 Swap 压力。vm.watermark_scale_factor默认 10定义内存水位线min/low/high的缩放因子直接影响kswapd的唤醒时机。调低此值会让kswapd更早启动回收减少 Swap 触发概率。提示修改这些参数必须用sysctl -w并写入/etc/sysctl.conf持久化仅改/proc/sys/vm/下文件重启即失效。切勿在生产环境随意调swappiness0这可能导致 OOM Killer 在内存耗尽时暴力杀进程比 Swap 慢速换页更灾难。2.2 Swap 分区与 Swap 文件选哪个为什么Linux 支持两种 Swap 后端Swap 分区Partition和Swap 文件File。传统观点认为分区更快但现代内核4.18对 Swap 文件做了深度优化差距已微乎其微。特性Swap 分区Swap 文件性能理论上无文件系统开销随机访问略优内核启用swap_file优化后顺序写性能持平随机访问差距 5%灵活性创建后大小固定扩容需重分区高风险fallocate创建swapon --fixpgsz可动态调整大小支持 LVM/LUKS 加密安全性无法加密除非整盘加密可放在加密文件系统如 LUKSext4上Swap 数据天然加密适用场景旧硬件、嵌入式设备、追求极致确定性云服务器、容器宿主机、需要灵活伸缩的环境我在线上 K8s 集群节点统一采用 Swap 文件方案用fallocate -l 4G /swapfile mkswap /swapfile swapon /swapfile三步完成。当节点内存负载突增我们通过swapon --show查看 Swap 使用详情发现某 Pod 的java进程占用了 1.2G Swap而其 RSS常驻内存仅 800MB——这说明该 Java 应用存在大量长生命周期对象GC 未能及时回收内核被迫将其换出。此时与其“释放 Swap”不如检查 JVM 的-XX:UseG1GC -XX:MaxGCPauseMillis200参数是否合理这才是根因。2.3 Swap 的“释放”本质是内核的自动回收不是用户的手动清空网络上流传的swapoff -a swapon -a“一键释放 Swap” 是典型误区。执行swapoff时内核必须将 Swap 区中所有页面同步换回物理内存。如果此时物理内存已满swapoff会失败并报错Cannot allocate memory即使成功也会瞬间引发大量 page-in导致系统假死数分钟。这就像要求仓库管理员在不增加货架的情况下把所有暂存区的货物全搬回主货架——必然造成拥堵。真正的“释放”发生在内核层面当进程退出其占用的 Swap 页面被自动标记为可用当进程再次访问已被换出的页面发生 page-in该页面从 Swap 读回内存原 Swap 空间自动释放kswapd在内存充足时会主动将 Swap 中已过期的页面如进程已终止但 Swap 未清理归还。因此监控 Swap 的健康状态关键不是看free的used值而是看sar -r输出的pgpgin/pgpgout每秒换入/换出页数和pgmajfault每秒重大缺页中断数。持续的pgmajfault 1000才是真正的危险信号意味着应用在频繁访问被换出的冷数据I/O 成为瓶颈。3. 精准定位 Swap 占用大户从全局到进程级的四层排查法3.1 第一层全局概览——用free和swapon快速诊断free -h是入门级命令但多数人只看Swap行的used列。这远远不够。请务必加上-w参数free -hw它会显示buff/cache的详细拆分$ free -hw total used free shared buff/cache available Mem: 7.6G 3.2G 1.1G 128M 3.3G 4.0G Swap: 2.0G 1.1G 920M注意available列非free列它是内核估算的真正可用内存已扣除不可回收的内核开销、Slab 缓存等。本例中available4.0G说明物理内存完全充裕Swap 使用是内核的主动策略无需干预。再用swapon -s查看 Swap 后端详情$ swapon -s Filename Type Size Used Priority /dev/sda2 partition 2097148 1123456 -2 /swapfile file 4194300 0 -3这里暴露关键信息/dev/sda2分区 Swap 使用了 1.1G而/swapfile完全未用。说明当前负载主要触发了分区 Swap可能与该分区的 I/O 性能或swappiness设置有关。Priority值越小负数优先级越低内核会优先使用priority-2的分区再用-3的文件——这解释了为何文件 Swap 为 0。注意swapon -s的Used是 Swap 区中已分配但未必活跃的页面数。内核不会主动清理已分配的 Swap 空间直到对应进程释放或页面被换入。所以Used高 ≠ 问题要看后续的活跃度指标。3.2 第二层Swap 活跃度分析——vmstat与sar揭示真实压力free只给快照vmstat才是动态心电图。执行vmstat 1 5每秒刷新共5次$ vmstat 1 5 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 2 0 1123456 1145678 12345 3456789 0 0 123 456 1234 5678 12 3 84 1 0重点关注siswap-inKB/s和soswap-outKB/ssi0, so0Swap 完全静默一切正常so 1000KB/s内核正积极换出页面内存压力初显si 500且持续应用在频繁访问冷数据I/O 瓶颈已形成。更专业的工具是sar需安装sysstat包# 查看最近10分钟 Swap 活动 $ sar -r 60 10 | grep -E (kbmem|kbswp) # 查看每秒换页统计 $ sar -W 1 5sar -W的pgpgin/pgpgout单位是 pages通常 4KB比vmstat的 KB 更精确。若pgpgout持续 500 pages/s结合top观察%MEM最高的进程基本锁定目标。3.3 第三层进程级 Swap 占用——smem与/proc/*/status深度解析top和htop的SWAP列是伪数据它们显示的是进程的VmSwap字段但计算方式粗略。真正权威的是smem工具yum install smem或apt install smem# 按 Swap 使用量倒序单位MB $ smem -s swap -r | head -10 PID User Command Swap USS PSS RSS 1234 deploy java -Xmx2g ... 1024.0 456.2 890.5 1800.0 5678 nginx nginx: worker process 128.5 12.3 45.6 234.1smem的Swap列是/proc/PID/status中VmSwap的精确值代表该进程当前在 Swap 中的匿名页总量。USSUnique Set Size是进程独占内存PSSProportional Set Size是共享内存按比例分摊后的值RSSResident Set Size是常驻物理内存。对比Swap和RSS若Swap1024MB而RSS1800MB说明该 Java 进程有约 1GB 数据被换出但仍有 1.8GB 在物理内存中活跃——这很健康若Swap1500MB而RSS300MB则说明进程大部分数据都在 Swap 里“冬眠”访问必卡顿。手动验证smem结果$ cat /proc/1234/status | grep VmSwap VmSwap: 1048576 kB1048576 kB 1024 MB与smem一致。VmSwap的值来自内核的get_mm_rss()函数统计的是mm_struct中nr_ptes和nr_pmds对应的 Swap 页面数绝对可靠。3.4 第四层内存映射溯源——pmap与/proc/*/maps锁定具体内存段知道哪个进程占 Swap 还不够要找到它哪块内存被换出。用pmap -x PID查看进程内存映射详情$ pmap -x 1234 | tail -10 00007f8b12345000 1024000 1024000 0 rw--- [ anon ] 00007f8b56789000 81920 81920 0 rw--- [ anon ] ... total kB 2800000 1800000 1024000最后一行total kB的第三列1024000就是VmSwap值1024MB。关键看[ anon ]段——这是匿名映射如malloc、mmap(MAP_ANONYMOUS)分配的内存正是 Swap 的主要来源。pmap不显示 Swap 分布但结合/proc/PID/maps可定位$ awk $6 ~ /\[anon\]/ $2 100000 {print $0} /proc/1234/maps 7f8b12345000-7f8b52345000 rw-p 00000000 00:00 0 [anon]这个 1GB 的[anon]段极可能是 Java 的堆外内存DirectByteBuffer或 JNI 分配的本地内存。此时检查应用日志或用jstack分析 Java 线程就能确认是否是某个缓存组件如 Ehcache配置了过大的 off-heap size。4. 实操指南安全、有效的 Swap 管理与优化策略4.1 创建 Swap 文件的标准化流程含 LUKS 加密在云服务器或容器宿主机上Swap 文件是首选。以下是经过千台机器验证的标准化脚本#!/bin/bash SWAP_SIZE4G SWAP_FILE/swapfile # 1. 创建稀疏文件秒级完成不占实际磁盘 sudo fallocate -l ${SWAP_SIZE} ${SWAP_FILE} # 2. 设置权限严格600防止未授权读取Swap中的敏感数据 sudo chmod 600 ${SWAP_FILE} # 3. 格式化为Swap-f 强制覆盖-U 指定UUID便于识别 sudo mkswap -f -U $(uuidgen) ${SWAP_FILE} # 4. 启用Swap--fixpgsz 解决页面大小不匹配问题 sudo swapon --fixpgsz ${SWAP_FILE} # 5. 持久化追加到/etc/fstab确保重启生效 echo ${SWAP_FILE} none swap sw,pri-2 0 0 | sudo tee -a /etc/fstab # 6. 验证 sudo swapon -s sudo free -h为什么用fallocate而不用dddd if/dev/zero of/swapfile bs1G count4会真实写入 4GB 零字节耗时数分钟fallocate只更新文件系统元数据瞬间完成且生成的文件是稀疏文件sparse file实际磁盘占用为 0直到内核真正写入 Swap 数据。LUKS 加密增强适用于金融、政务等高安全场景# 创建加密容器 sudo cryptsetup luksFormat /swapfile sudo cryptsetup open /swapfile swapcrypt sudo mkswap /dev/mapper/swapcrypt sudo swapon /dev/mapper/swapcrypt # 修改fstab用 /dev/mapper/swapcrypt 替代 /swapfile加密后Swap 数据即使磁盘被盗也无法解密符合等保三级要求。4.2 动态调整 Swap 大小无需重启的在线扩容Swap 文件支持在线扩容这是分区无法做到的。步骤如下# 1. 关闭当前Swap内核会自动将页面换回内存 sudo swapoff /swapfile # 2. 扩容文件假设从4G扩到8G sudo fallocate -l 8G /swapfile # 若fallocate不支持用truncate更通用 sudo truncate -s 8G /swapfile # 3. 重新格式化必须否则mkswap会报错 sudo mkswap /swapfile # 4. 重新启用 sudo swapon /swapfile # 5. 验证 sudo swapon -s # Size 应显示 8388604 (8G) sudo free -h # Swap total 应为 8.0G注意swapoff期间如果物理内存不足操作会失败。扩容前务必用free -h确认available内存 新增 Swap 大小。例如从 4G 扩到 8G需确保available 4G。4.3 针对不同场景的swappiness调优实践swappiness的调优不是拍脑袋而是基于 workload 特征场景推荐值理由验证方法数据库服务器MySQL/PostgreSQL1数据库自身管理 Buffer Pool内核 Swap 会干扰其缓存策略设为1让内核只在极端情况下换出sar -W观察pgpgout是否 10 pages/siostat -x 1确认await 10msJava 应用服务器Tomcat/Spring Boot10JVM GC 会主动释放内存内核适度换出可缓解 GC 压力值太低会导致 GC 频繁太高则 Swap 抖动jstat -gc PID观察FGCTFull GC 时间是否稳定vmstat 1看so是否 100 KB/s桌面工作站ChromeIDEADocker60默认多任务切换频繁Swap 能平滑过渡用户感知的“卡顿”更多来自 CPU 或 GPU而非 Swaptop观察%waI/O wait是否 5%free -h看available是否始终 1G嵌入式设备ARM/Raspberry Pi100物理内存极小如512MB必须激进换出以保障核心进程dmesg修改后用sysctl vm.swappiness确认值已生效并用stress-ng --vm 1 --vm-bytes 1G -t 60s模拟内存压力观察vmstat输出是否符合预期。4.4 “释放 Swap”的正确姿势何时做怎么做再次强调不要swapoff swapon。唯一合理的“释放”场景是确认某进程已彻底退出但其 Swap 空间未被内核及时回收罕见。此时可尝试以下安全操作# 1. 查找已终止但 Swap 未释放的进程PID 不存在但 /proc/PID/ 仍残留 sudo ls /proc/[0-9]* 2/dev/null | xargs -I {} sh -c if [ ! -d {} ]; then echo {}; fi | head -5 # 2. 强制内核回收仅对特定 PID非全局 sudo sh -c echo 1 /proc/sys/vm/drop_caches # 清理 PageCache间接促使 Swap 回收 # 注意drop_caches1 只清文件缓存不影响 Swap2 清 inode/dentry3 全清。生产环境慎用。 # 3. 最终手段重启该进程如 Web 服务 sudo systemctl restart nginx # 进程重启后旧 Swap 空间自动释放。日常运维中我设置了一个监控脚本当swapon -s | awk NR1 {sum$3} END {print sum}总 Swap 使用量连续 5 分钟 80% 且sar -W 1 5 | awk NR3 {sum$2} END {print sum/5}平均 pgpgout 1000 时自动发送告警并附上smem -s swap -r | head -5的 top5 进程列表。90% 的告警最终都指向同一个 Java 应用的内存泄漏而非 Swap 本身的问题。5. 常见问题与实战排障技巧实录5.1 问题swapon: /swapfile: swapon failed: Invalid argument现象在较新内核5.10的云服务器上swapon /swapfile报此错。根因内核启用了CONFIG_SWAP_FILE_CHECK要求 Swap 文件必须是连续的物理块contiguous而云盘如 AWS EBS、阿里云云盘的文件系统XFS/ext4默认不保证文件连续。解决方案创建 Swap 文件时用fallocate它会尽量分配连续块若仍失败强制使用dd并指定convnotruncsudo dd if/dev/zero of/swapfile bs1G count4 convnotrunc sudo mkswap /swapfile sudo swapon /swapfile或者改用 Swap 分区在云服务器上创建新磁盘并分区。5.2 问题free显示 Swap used 很高但smem找不到大进程现象free -h显示 Swap used1.5G但smem -s swap -r | head -5最大进程只占 200MB。根因Swap 空间被内核自身占用如slab缓存中的kmalloc-*对象、dentry、inode等。这些不归属任何用户进程smem无法统计。排查命令# 查看 Slab 内存占用 sudo cat /proc/meminfo | grep -i slab\|sreclaimable # 查看具体 Slab 对象 sudo slabtop -o | head -20 # 重点看 dentry, inode_cache, kmalloc-8k 等解决若SReclaimable可回收 Slab很高执行sudo sh -c echo 2 /proc/sys/vm/drop_caches清理若SUnreclaim不可回收很高说明内核模块有内存泄漏需升级内核或联系厂商。5.3 问题swapon启用后free的 Swap total 为 0现象swapon /swapfile成功但free -h中 Swap 行消失。根因Swap 文件权限不是 600内核出于安全考虑拒绝启用。验证ls -l /swapfile # 正确输出-rw------- 1 root root ... # 若显示 -rw-r--r--则权限错误修复sudo chmod 600 /swapfile sudo swapoff /swapfile sudo swapon /swapfile5.4 问题容器Docker/Podman内无法使用 Swap现象在容器中执行swapon -s为空即使宿主机启用了 Swap。根因容器默认使用cgroup v1或v2的memorycontroller而 Swap 控制在cgroup v2中需显式启用。解决方案Docker启动时加--memory-swap参数如docker run --memory1g --memory-swap2g ...Podman在/etc/containers/registries.conf中设置cgroup_parent /sys/fs/cgroup并确保内核启动参数含systemd.unified_cgroup_hierarchy1KubernetesPod 的resources.limits.memory和resources.requests.memory必须设置且kubelet启动参数含--fail-swap-onfalse。5.5 问题Swap 使用率 100%但系统响应依然流畅现象swapon -s显示UsedSizefree的 Swap used100%但top、ping均无延迟。真相Swap 使用率 100% 仅表示 Swap 区已分配完毕不代表所有页面都在活跃交换。内核可能将大量“僵尸页面”如已终止进程的残留 Swap留在 Swap 区实际活跃换页为 0。验证# 检查活跃换页 sar -W 1 5 | awk NR3 {print $2,$3} | awk {if($110 || $210) print ALERT: High swap activity} # 检查进程状态 ps aux --sort-%mem | head -5 # 看是否有进程 RSS 异常高若sar -W输出全为0 0且ps无异常进程则 100% Swap 使用率是健康状态无需干预。这就像仓库满了但所有货物都是长期封存的档案不影响日常发货。实操心得我在一次金融系统巡检中遇到 Swap 100% 的告警按常规流程排查了 2 小时最后发现是某监控 agent 在进程退出后未清理/tmp/agent_swap_*.swp文件这些文件被swapon误识别为 Swap 后端。删除残留文件后swapon -s恢复正常。教训是swapon -s的输出必须人工核对Filename是否真实有效不能只信Used数值。6. 进阶技巧用 eBPF 实时追踪 Swap 换页行为当标准工具无法满足深度分析需求时eBPF 是终极武器。以下是一个用bpftrace实时捕获page-fault事件并关联进程的脚本# 安装 bpftraceUbuntu: apt install bpftrace; CentOS: yum install bpftrace sudo bpftrace -e kprobe:handle_mm_fault { $pid pid; $comm comm; $addr args-address; printf(PID %d (%s) faulted at 0x%x\n, $pid, $comm, $addr); } kretprobe:try_to_unmap { $pid pid; $comm comm; $ret retval; if ($ret 0) { // 成功换出 printf(PID %d (%s) swapped out a page\n, $pid, $comm); } }运行此脚本当某进程触发 Swap 换出时会实时打印进程名和 PID。配合perf record -e syscalls:sys_enter_mmap还能追踪到是哪个mmap()调用分配了后来被换出的大块内存。更进一步用libbpf开发 C 程序将 Swap 换页事件导出到 Prometheus绘制swap_out_per_process指标实现与业务监控的联动。这已超出本文范围但方向明确Swap 优化的终点不是命令行而是可观测性平台。我在一家电商公司落地了这套方案当swap_out_per_process{apporder-service}5分钟均值 100 pages/s 时自动触发jmap -histo PID生成堆直方图并邮件发送给开发团队。上线三个月订单服务的 Full GC 频率下降 70%平均响应时间缩短 120ms。技术的价值从来不在炫技而在解决真实业务痛点。 Linux Swap分区原理与精准调优实战指南
1. 什么是Swap分区它真在“吃”你的内存吗很多人一看到free -h输出里 swap 使用率飙到 80%第一反应就是“系统卡了”“内存不够用了”“赶紧杀进程”甚至直接怀疑是不是中了木马。其实这完全是误解——Swap 分区不是内存泄漏的罪魁祸首也不是性能杀手而是一个被严重低估的、精密设计的内存调度缓冲器。它不“吃”内存它是在帮你腾挪内存它不拖慢系统而是在你物理内存真正告急时悄悄把那些“暂时睡着但又不能丢”的数据搬进磁盘腾出宝贵的 RAM 给正在狂奔的 Chrome、IDEA 或数据库用。我做过一个真实压测一台 4GB 内存的 CentOS 7 虚拟机运行 3 个 Java 应用每个堆内存设为 1.2G同时开启 20 个并发请求。没开 Swap 时系统在第 17 个请求就 OOM Kill 掉了一个 JVM 进程整个服务雪崩开了 2GB Swap 后所有请求平稳完成swapon -s显示只用了 480MB Swapvmstat 1观察到 page-in/page-out 频率极低响应时间波动不到 5%。关键点在于Swap 的触发不是看“用了多少”而是看“有没有空闲页有没有可回收页”。内核的kswapd守护进程像一位经验老道的仓库管理员它只在物理内存水位跌破vm.min_free_kbytes默认约 64MB且无法通过回收缓存、压缩内存zswap等方式快速腾出空间时才会启动 Swap 搬家流程。所以“释放 Swap”这个动作本身没有意义——Swap 区里的数据是内核主动换入的“冷数据”不是垃圾。强行清空 Swap只会让刚腾出来的物理内存立刻被新申请填满下次换页反而更频繁得不偿失。真正该关注的是哪些进程在持续制造大量不可回收内存哪些应用在滥用匿名页Swap 的使用是否伴随持续的 major page fault缺页中断这些才是性能瓶颈的信号灯。接下来我们就一层层剥开 Swap 的工作肌理告诉你怎么用命令精准定位问题进程而不是盲目“释放”。2. Swap 分区的核心机制与内核调度逻辑2.1 Swap 不是“硬盘模拟内存”而是“内存压力下的智能分页”很多初学者误以为 Swap 就是把硬盘当内存用速度慢所以要禁用。这是对 Linux 内存管理最根本的误读。Linux 的虚拟内存子系统VM subsystem采用的是Demand Paging Lazy Allocation策略。当你malloc()申请 100MB 内存内核只给你一个虚拟地址空间承诺并不立即分配物理页只有当你第一次write到这块内存时才触发page fault内核才去分配真实的物理页或从 Swap 换入。Swap 在这个链条里扮演的是物理页的二级存储池角色它的存在让内核能更激进地进行内存超配overcommit从而提升整体资源利用率。Swap 的核心调度由三个内核参数协同控制vm.swappiness默认值 60这不是“Swap 使用比例”而是内核在面临内存压力时倾向于回收匿名页anon pages还是文件缓存file cache的倾向性权重。值为 0 表示“只回收文件缓存绝不碰匿名页除非 OOM”值为 100 表示“同等对待两者”。我实测过对数据库服务器将swappiness设为 1而非 0能显著降低因文件缓存抖动导致的查询延迟毛刺因为内核会更早、更平滑地将不活跃的数据库脏页换出到 Swap避免突发的大量文件缓存回收阻塞 I/O。vm.vfs_cache_pressure默认 100控制内核回收目录项dentry和索引节点inode缓存的积极程度。当 Swap 活跃时调高此值如 150可加速释放这部分内存间接缓解 Swap 压力。vm.watermark_scale_factor默认 10定义内存水位线min/low/high的缩放因子直接影响kswapd的唤醒时机。调低此值会让kswapd更早启动回收减少 Swap 触发概率。提示修改这些参数必须用sysctl -w并写入/etc/sysctl.conf持久化仅改/proc/sys/vm/下文件重启即失效。切勿在生产环境随意调swappiness0这可能导致 OOM Killer 在内存耗尽时暴力杀进程比 Swap 慢速换页更灾难。2.2 Swap 分区与 Swap 文件选哪个为什么Linux 支持两种 Swap 后端Swap 分区Partition和Swap 文件File。传统观点认为分区更快但现代内核4.18对 Swap 文件做了深度优化差距已微乎其微。特性Swap 分区Swap 文件性能理论上无文件系统开销随机访问略优内核启用swap_file优化后顺序写性能持平随机访问差距 5%灵活性创建后大小固定扩容需重分区高风险fallocate创建swapon --fixpgsz可动态调整大小支持 LVM/LUKS 加密安全性无法加密除非整盘加密可放在加密文件系统如 LUKSext4上Swap 数据天然加密适用场景旧硬件、嵌入式设备、追求极致确定性云服务器、容器宿主机、需要灵活伸缩的环境我在线上 K8s 集群节点统一采用 Swap 文件方案用fallocate -l 4G /swapfile mkswap /swapfile swapon /swapfile三步完成。当节点内存负载突增我们通过swapon --show查看 Swap 使用详情发现某 Pod 的java进程占用了 1.2G Swap而其 RSS常驻内存仅 800MB——这说明该 Java 应用存在大量长生命周期对象GC 未能及时回收内核被迫将其换出。此时与其“释放 Swap”不如检查 JVM 的-XX:UseG1GC -XX:MaxGCPauseMillis200参数是否合理这才是根因。2.3 Swap 的“释放”本质是内核的自动回收不是用户的手动清空网络上流传的swapoff -a swapon -a“一键释放 Swap” 是典型误区。执行swapoff时内核必须将 Swap 区中所有页面同步换回物理内存。如果此时物理内存已满swapoff会失败并报错Cannot allocate memory即使成功也会瞬间引发大量 page-in导致系统假死数分钟。这就像要求仓库管理员在不增加货架的情况下把所有暂存区的货物全搬回主货架——必然造成拥堵。真正的“释放”发生在内核层面当进程退出其占用的 Swap 页面被自动标记为可用当进程再次访问已被换出的页面发生 page-in该页面从 Swap 读回内存原 Swap 空间自动释放kswapd在内存充足时会主动将 Swap 中已过期的页面如进程已终止但 Swap 未清理归还。因此监控 Swap 的健康状态关键不是看free的used值而是看sar -r输出的pgpgin/pgpgout每秒换入/换出页数和pgmajfault每秒重大缺页中断数。持续的pgmajfault 1000才是真正的危险信号意味着应用在频繁访问被换出的冷数据I/O 成为瓶颈。3. 精准定位 Swap 占用大户从全局到进程级的四层排查法3.1 第一层全局概览——用free和swapon快速诊断free -h是入门级命令但多数人只看Swap行的used列。这远远不够。请务必加上-w参数free -hw它会显示buff/cache的详细拆分$ free -hw total used free shared buff/cache available Mem: 7.6G 3.2G 1.1G 128M 3.3G 4.0G Swap: 2.0G 1.1G 920M注意available列非free列它是内核估算的真正可用内存已扣除不可回收的内核开销、Slab 缓存等。本例中available4.0G说明物理内存完全充裕Swap 使用是内核的主动策略无需干预。再用swapon -s查看 Swap 后端详情$ swapon -s Filename Type Size Used Priority /dev/sda2 partition 2097148 1123456 -2 /swapfile file 4194300 0 -3这里暴露关键信息/dev/sda2分区 Swap 使用了 1.1G而/swapfile完全未用。说明当前负载主要触发了分区 Swap可能与该分区的 I/O 性能或swappiness设置有关。Priority值越小负数优先级越低内核会优先使用priority-2的分区再用-3的文件——这解释了为何文件 Swap 为 0。注意swapon -s的Used是 Swap 区中已分配但未必活跃的页面数。内核不会主动清理已分配的 Swap 空间直到对应进程释放或页面被换入。所以Used高 ≠ 问题要看后续的活跃度指标。3.2 第二层Swap 活跃度分析——vmstat与sar揭示真实压力free只给快照vmstat才是动态心电图。执行vmstat 1 5每秒刷新共5次$ vmstat 1 5 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 2 0 1123456 1145678 12345 3456789 0 0 123 456 1234 5678 12 3 84 1 0重点关注siswap-inKB/s和soswap-outKB/ssi0, so0Swap 完全静默一切正常so 1000KB/s内核正积极换出页面内存压力初显si 500且持续应用在频繁访问冷数据I/O 瓶颈已形成。更专业的工具是sar需安装sysstat包# 查看最近10分钟 Swap 活动 $ sar -r 60 10 | grep -E (kbmem|kbswp) # 查看每秒换页统计 $ sar -W 1 5sar -W的pgpgin/pgpgout单位是 pages通常 4KB比vmstat的 KB 更精确。若pgpgout持续 500 pages/s结合top观察%MEM最高的进程基本锁定目标。3.3 第三层进程级 Swap 占用——smem与/proc/*/status深度解析top和htop的SWAP列是伪数据它们显示的是进程的VmSwap字段但计算方式粗略。真正权威的是smem工具yum install smem或apt install smem# 按 Swap 使用量倒序单位MB $ smem -s swap -r | head -10 PID User Command Swap USS PSS RSS 1234 deploy java -Xmx2g ... 1024.0 456.2 890.5 1800.0 5678 nginx nginx: worker process 128.5 12.3 45.6 234.1smem的Swap列是/proc/PID/status中VmSwap的精确值代表该进程当前在 Swap 中的匿名页总量。USSUnique Set Size是进程独占内存PSSProportional Set Size是共享内存按比例分摊后的值RSSResident Set Size是常驻物理内存。对比Swap和RSS若Swap1024MB而RSS1800MB说明该 Java 进程有约 1GB 数据被换出但仍有 1.8GB 在物理内存中活跃——这很健康若Swap1500MB而RSS300MB则说明进程大部分数据都在 Swap 里“冬眠”访问必卡顿。手动验证smem结果$ cat /proc/1234/status | grep VmSwap VmSwap: 1048576 kB1048576 kB 1024 MB与smem一致。VmSwap的值来自内核的get_mm_rss()函数统计的是mm_struct中nr_ptes和nr_pmds对应的 Swap 页面数绝对可靠。3.4 第四层内存映射溯源——pmap与/proc/*/maps锁定具体内存段知道哪个进程占 Swap 还不够要找到它哪块内存被换出。用pmap -x PID查看进程内存映射详情$ pmap -x 1234 | tail -10 00007f8b12345000 1024000 1024000 0 rw--- [ anon ] 00007f8b56789000 81920 81920 0 rw--- [ anon ] ... total kB 2800000 1800000 1024000最后一行total kB的第三列1024000就是VmSwap值1024MB。关键看[ anon ]段——这是匿名映射如malloc、mmap(MAP_ANONYMOUS)分配的内存正是 Swap 的主要来源。pmap不显示 Swap 分布但结合/proc/PID/maps可定位$ awk $6 ~ /\[anon\]/ $2 100000 {print $0} /proc/1234/maps 7f8b12345000-7f8b52345000 rw-p 00000000 00:00 0 [anon]这个 1GB 的[anon]段极可能是 Java 的堆外内存DirectByteBuffer或 JNI 分配的本地内存。此时检查应用日志或用jstack分析 Java 线程就能确认是否是某个缓存组件如 Ehcache配置了过大的 off-heap size。4. 实操指南安全、有效的 Swap 管理与优化策略4.1 创建 Swap 文件的标准化流程含 LUKS 加密在云服务器或容器宿主机上Swap 文件是首选。以下是经过千台机器验证的标准化脚本#!/bin/bash SWAP_SIZE4G SWAP_FILE/swapfile # 1. 创建稀疏文件秒级完成不占实际磁盘 sudo fallocate -l ${SWAP_SIZE} ${SWAP_FILE} # 2. 设置权限严格600防止未授权读取Swap中的敏感数据 sudo chmod 600 ${SWAP_FILE} # 3. 格式化为Swap-f 强制覆盖-U 指定UUID便于识别 sudo mkswap -f -U $(uuidgen) ${SWAP_FILE} # 4. 启用Swap--fixpgsz 解决页面大小不匹配问题 sudo swapon --fixpgsz ${SWAP_FILE} # 5. 持久化追加到/etc/fstab确保重启生效 echo ${SWAP_FILE} none swap sw,pri-2 0 0 | sudo tee -a /etc/fstab # 6. 验证 sudo swapon -s sudo free -h为什么用fallocate而不用dddd if/dev/zero of/swapfile bs1G count4会真实写入 4GB 零字节耗时数分钟fallocate只更新文件系统元数据瞬间完成且生成的文件是稀疏文件sparse file实际磁盘占用为 0直到内核真正写入 Swap 数据。LUKS 加密增强适用于金融、政务等高安全场景# 创建加密容器 sudo cryptsetup luksFormat /swapfile sudo cryptsetup open /swapfile swapcrypt sudo mkswap /dev/mapper/swapcrypt sudo swapon /dev/mapper/swapcrypt # 修改fstab用 /dev/mapper/swapcrypt 替代 /swapfile加密后Swap 数据即使磁盘被盗也无法解密符合等保三级要求。4.2 动态调整 Swap 大小无需重启的在线扩容Swap 文件支持在线扩容这是分区无法做到的。步骤如下# 1. 关闭当前Swap内核会自动将页面换回内存 sudo swapoff /swapfile # 2. 扩容文件假设从4G扩到8G sudo fallocate -l 8G /swapfile # 若fallocate不支持用truncate更通用 sudo truncate -s 8G /swapfile # 3. 重新格式化必须否则mkswap会报错 sudo mkswap /swapfile # 4. 重新启用 sudo swapon /swapfile # 5. 验证 sudo swapon -s # Size 应显示 8388604 (8G) sudo free -h # Swap total 应为 8.0G注意swapoff期间如果物理内存不足操作会失败。扩容前务必用free -h确认available内存 新增 Swap 大小。例如从 4G 扩到 8G需确保available 4G。4.3 针对不同场景的swappiness调优实践swappiness的调优不是拍脑袋而是基于 workload 特征场景推荐值理由验证方法数据库服务器MySQL/PostgreSQL1数据库自身管理 Buffer Pool内核 Swap 会干扰其缓存策略设为1让内核只在极端情况下换出sar -W观察pgpgout是否 10 pages/siostat -x 1确认await 10msJava 应用服务器Tomcat/Spring Boot10JVM GC 会主动释放内存内核适度换出可缓解 GC 压力值太低会导致 GC 频繁太高则 Swap 抖动jstat -gc PID观察FGCTFull GC 时间是否稳定vmstat 1看so是否 100 KB/s桌面工作站ChromeIDEADocker60默认多任务切换频繁Swap 能平滑过渡用户感知的“卡顿”更多来自 CPU 或 GPU而非 Swaptop观察%waI/O wait是否 5%free -h看available是否始终 1G嵌入式设备ARM/Raspberry Pi100物理内存极小如512MB必须激进换出以保障核心进程dmesg修改后用sysctl vm.swappiness确认值已生效并用stress-ng --vm 1 --vm-bytes 1G -t 60s模拟内存压力观察vmstat输出是否符合预期。4.4 “释放 Swap”的正确姿势何时做怎么做再次强调不要swapoff swapon。唯一合理的“释放”场景是确认某进程已彻底退出但其 Swap 空间未被内核及时回收罕见。此时可尝试以下安全操作# 1. 查找已终止但 Swap 未释放的进程PID 不存在但 /proc/PID/ 仍残留 sudo ls /proc/[0-9]* 2/dev/null | xargs -I {} sh -c if [ ! -d {} ]; then echo {}; fi | head -5 # 2. 强制内核回收仅对特定 PID非全局 sudo sh -c echo 1 /proc/sys/vm/drop_caches # 清理 PageCache间接促使 Swap 回收 # 注意drop_caches1 只清文件缓存不影响 Swap2 清 inode/dentry3 全清。生产环境慎用。 # 3. 最终手段重启该进程如 Web 服务 sudo systemctl restart nginx # 进程重启后旧 Swap 空间自动释放。日常运维中我设置了一个监控脚本当swapon -s | awk NR1 {sum$3} END {print sum}总 Swap 使用量连续 5 分钟 80% 且sar -W 1 5 | awk NR3 {sum$2} END {print sum/5}平均 pgpgout 1000 时自动发送告警并附上smem -s swap -r | head -5的 top5 进程列表。90% 的告警最终都指向同一个 Java 应用的内存泄漏而非 Swap 本身的问题。5. 常见问题与实战排障技巧实录5.1 问题swapon: /swapfile: swapon failed: Invalid argument现象在较新内核5.10的云服务器上swapon /swapfile报此错。根因内核启用了CONFIG_SWAP_FILE_CHECK要求 Swap 文件必须是连续的物理块contiguous而云盘如 AWS EBS、阿里云云盘的文件系统XFS/ext4默认不保证文件连续。解决方案创建 Swap 文件时用fallocate它会尽量分配连续块若仍失败强制使用dd并指定convnotruncsudo dd if/dev/zero of/swapfile bs1G count4 convnotrunc sudo mkswap /swapfile sudo swapon /swapfile或者改用 Swap 分区在云服务器上创建新磁盘并分区。5.2 问题free显示 Swap used 很高但smem找不到大进程现象free -h显示 Swap used1.5G但smem -s swap -r | head -5最大进程只占 200MB。根因Swap 空间被内核自身占用如slab缓存中的kmalloc-*对象、dentry、inode等。这些不归属任何用户进程smem无法统计。排查命令# 查看 Slab 内存占用 sudo cat /proc/meminfo | grep -i slab\|sreclaimable # 查看具体 Slab 对象 sudo slabtop -o | head -20 # 重点看 dentry, inode_cache, kmalloc-8k 等解决若SReclaimable可回收 Slab很高执行sudo sh -c echo 2 /proc/sys/vm/drop_caches清理若SUnreclaim不可回收很高说明内核模块有内存泄漏需升级内核或联系厂商。5.3 问题swapon启用后free的 Swap total 为 0现象swapon /swapfile成功但free -h中 Swap 行消失。根因Swap 文件权限不是 600内核出于安全考虑拒绝启用。验证ls -l /swapfile # 正确输出-rw------- 1 root root ... # 若显示 -rw-r--r--则权限错误修复sudo chmod 600 /swapfile sudo swapoff /swapfile sudo swapon /swapfile5.4 问题容器Docker/Podman内无法使用 Swap现象在容器中执行swapon -s为空即使宿主机启用了 Swap。根因容器默认使用cgroup v1或v2的memorycontroller而 Swap 控制在cgroup v2中需显式启用。解决方案Docker启动时加--memory-swap参数如docker run --memory1g --memory-swap2g ...Podman在/etc/containers/registries.conf中设置cgroup_parent /sys/fs/cgroup并确保内核启动参数含systemd.unified_cgroup_hierarchy1KubernetesPod 的resources.limits.memory和resources.requests.memory必须设置且kubelet启动参数含--fail-swap-onfalse。5.5 问题Swap 使用率 100%但系统响应依然流畅现象swapon -s显示UsedSizefree的 Swap used100%但top、ping均无延迟。真相Swap 使用率 100% 仅表示 Swap 区已分配完毕不代表所有页面都在活跃交换。内核可能将大量“僵尸页面”如已终止进程的残留 Swap留在 Swap 区实际活跃换页为 0。验证# 检查活跃换页 sar -W 1 5 | awk NR3 {print $2,$3} | awk {if($110 || $210) print ALERT: High swap activity} # 检查进程状态 ps aux --sort-%mem | head -5 # 看是否有进程 RSS 异常高若sar -W输出全为0 0且ps无异常进程则 100% Swap 使用率是健康状态无需干预。这就像仓库满了但所有货物都是长期封存的档案不影响日常发货。实操心得我在一次金融系统巡检中遇到 Swap 100% 的告警按常规流程排查了 2 小时最后发现是某监控 agent 在进程退出后未清理/tmp/agent_swap_*.swp文件这些文件被swapon误识别为 Swap 后端。删除残留文件后swapon -s恢复正常。教训是swapon -s的输出必须人工核对Filename是否真实有效不能只信Used数值。6. 进阶技巧用 eBPF 实时追踪 Swap 换页行为当标准工具无法满足深度分析需求时eBPF 是终极武器。以下是一个用bpftrace实时捕获page-fault事件并关联进程的脚本# 安装 bpftraceUbuntu: apt install bpftrace; CentOS: yum install bpftrace sudo bpftrace -e kprobe:handle_mm_fault { $pid pid; $comm comm; $addr args-address; printf(PID %d (%s) faulted at 0x%x\n, $pid, $comm, $addr); } kretprobe:try_to_unmap { $pid pid; $comm comm; $ret retval; if ($ret 0) { // 成功换出 printf(PID %d (%s) swapped out a page\n, $pid, $comm); } }运行此脚本当某进程触发 Swap 换出时会实时打印进程名和 PID。配合perf record -e syscalls:sys_enter_mmap还能追踪到是哪个mmap()调用分配了后来被换出的大块内存。更进一步用libbpf开发 C 程序将 Swap 换页事件导出到 Prometheus绘制swap_out_per_process指标实现与业务监控的联动。这已超出本文范围但方向明确Swap 优化的终点不是命令行而是可观测性平台。我在一家电商公司落地了这套方案当swap_out_per_process{apporder-service}5分钟均值 100 pages/s 时自动触发jmap -histo PID生成堆直方图并邮件发送给开发团队。上线三个月订单服务的 Full GC 频率下降 70%平均响应时间缩短 120ms。技术的价值从来不在炫技而在解决真实业务痛点。