OOM就一定要启用swap?

本文讨论了Linux系统中swap的作用,如何通过调整swappiness值和overcommit_memory参数来确保数据库性能和稳定性。DBA应根据数据运行状态合理配置这些内存管理参数,防止OOM事件的发生。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

529872795033469db6df9b7dc27e3580_3.png“在技术群中到,看到有人数据库OOM了,DBA没有去排查高占用的进程,而是去排查为什么swap没有生效,我觉得很有意思。为此我查阅了一些资料,先给大家讲讲swap的作用是什么”

swap是什么

当系统物理内存不足时,Linux 会将一部分内存页移动到交换空间中,从而释放物理内存给当前正在执行的进程使用。这样可以避免因为内存不足而导致系统性能下降或进程被终止。 如果系统发生崩溃或意外关机,交换空间中保存的数据可以用于恢复系统状态。在重新启动时,Linux 可以将交换空间中的数据加载回物理内存,从而尽可能地恢复之前的工作状态。实际上就是借助磁盘空间进行存放内存页。我们管swap为虚拟内存

查看swap 的常见指令

显示swap分区大小
free -m 

image.png
此时数字显示的单位MBi

查看swappiness值
cat /proc/sys/vm/swappiness
改变当前值
 sudo sysctl vm.swappiness=0

image.png
使其生效

  sysctl -p

swappiness值是控制内存页从物理内存换出到swap的一个指标。当内存达到100-swappiness时,此时得内存会被移到swap中。当进程被移动swap中去的时候,此时该进程的效率远不及在物理内存中的效果,此时数据库的运行稳定性依然会受到很大的影响。

如果想让数据库的性能尽量平稳,就应该把此值设置尽量的高。第二个需要调整的虚拟内存参数是“overcommit”。在Linux中,程序调用malloc()函数分配内存时,只分配虚拟内存,真正的物理内存并没有被分配,只有进程真正需要使用时才会分配物理内存。这种申请内存后并不会马上使用的技术就叫“Overcommit”技术。Overcommit技术的优势在于,系统中运行的进程可以分配的内存数可以超过机器上拥有的物理内存,其劣势在于,当进程真正需要内存时,可能没有可用的物理内存可以使用,此时需把其他进程使用的内存放到SWAP区中,但是如果SWAP中也放不下,就会发生OOMkiller,它会选择杀死一些用户态的进程以释放内存。vm.overcommit参数可控制调用malloc()函数时分配内存的行为,此参数可以取以下3个值。
·0:启发式策略,表示Linux将启发式地检查是否有足够的内存可以Overcommit,如果有则成功调用malloc(),内存申请成功;否则,内存申请失败,并把错误返回给应用程序。这种方式并不能完全避免OOM killer。
·1:总是成功调用malloc(),并不管当前内存的实际情况。
·2:不允许Overcommit,即当分配给所有进程的内存超过swapd大小+N%×物理内存时,会分配失败,N%是一个百分比,该值是由另一个参数vm.overcommit_ratio控制的。上面参数值中的“0”和“1”都不能避免OOM killer,所以在数据库中要把此参数设置为“2”,命令如下:

sudo sysctl -w vm.overcommit_memory=2

查看overcommit_memory当前值

sudo sysctl vm.overcommit_memory

vm.overcommit_ratio的设置

修改vm.overcommit_ratio当前值

sudo sysctl -w vm.overcommit_memory=2

查看vm.overcommit_ratio当前值

sudo sysctl vm.overcommit_ratio

image.png

另外我在技术交流群中发现,其他的群友给出了一下代码

列出系统中虚拟内存交换最大的进程,以及它们的名称和 PID(默认前十行)
for file in /proc/*/status ; do awk '/VmSwap|Name|^Pid/{printf $2 " " $3}END{ print ""}' $file; done | sort -k 3 -n -r | head

140357798_0_final.png

至于数据据该不该配置swap ,我认为身为DBA一定要非常了解数据的运行状态,对相关参数给出合理的配置。

<think>嗯,用户需要解决Linux系统中Swap空间几乎用尽的问题。这个问题在服务器运维中很常见,尤其在高负载或内存不足的场景下。 用户提供的引用材料很有价值,从这些材料可以看出几个关键点: 1. Swap空间耗尽会导致系统卡顿甚至崩溃[^1] 2. Swap是物理内存不足时的扩展空间[^2] 3. 可以通过调整swappiness参数控制Swap使用策略[^3] 4. 可以临时创建Swap文件应急[^4] 用户的核心诉求是解决方案,我需要给出系统化的处理步骤。考虑到用户可能是运维人员,应该提供从诊断到根治的完整方案。 首先需要区分临时缓解和根本解决两个层面: 临时方案包括释放现有Swap和增加Swap空间,这在引用[4]中提到了创建Swap文件的方法。根本解决需要分析内存使用情况,可能是应用程序内存泄漏或物理内存确实不足。 特别要注意引用[3]提到的swappiness参数调整,这个对性能优化很关键。默认值60可能过高,对于数据库服务器通常建议调低。 在给出具体命令时要注意安全性,比如swapoff操作可能导致内存压力骤增,需要提醒用户谨慎操作。对于永久性修改/etc/fstab的步骤,必须强调备份的重要性。 用户没有提供具体系统版本,所以命令需要保持通用性。可以补充说明不同发行版的细微差异,比如CentOS和Ubuntu的服务管理命令不同。 最后要提醒监控的重要性,建议用户安装监控工具。毕竟预防比补救更重要,这也是专业运维应有的思路。</think>以下是针对Linux Swap空间耗尽的系统化解决方案,结合诊断、临时缓解和根本解决措施: --- ### **一、紧急诊断与临时缓解** 1. **确认Swap状态** ```bash free -h # 查看内存/Swap使用总量 swapon --show # 显示活动的Swap分区/文件 vmstat 1 5 # 监控内存(si/so列)、Swap(si/so)交换频率 ``` - 若`si`(swap-in)和`so`(swap-out)持续不为零,表明系统频繁使用Swap[^2]。 2. **释放已用Swap空间** ```bash swapoff -a # 关闭所有Swap(需确保物理内存足够) swapon -a # 重新激活Swap ``` **注意**:执行前确保空闲内存 > 已用Swap,否则可能触发OOM(内存溢出)[^1]。 3. **清理缓存(治标不治本)** ```bash sync; echo 3 > /proc/sys/vm/drop_caches # 释放PageCache/Slab等缓存 ``` --- ### **二、扩容Swap空间(临时/永久)** 1. **创建临时Swap文件**(参考[^4]) ```bash dd if=/dev/zero of=/tmp/swapfile bs=1M count=2048 # 创建2GB文件 chmod 600 /tmp/swapfile mkswap /tmp/swapfile swapon /tmp/swapfile ``` - 用`df -h`确认磁盘空间足够,避免耗尽inode或存储空间。 2. **永久增加Swap** ```bash sudo fallocate -l 4G /swapfile # 更高效的文件分配 sudo mkswap /swapfile sudo swapon /swapfile echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab # 开机挂载 ``` --- ### **三、根本性优化** 1. **调整Swap使用策略** ```bash echo 'vm.swappiness=10' >> /etc/sysctl.conf # 降低Swap使用倾向(范围0-100) sysctl -p # 推荐值: 数据库服务器设为1-10,桌面环境30-60[^3] ``` - **`swappiness=0`**:除非内存耗尽,否则不用Swap - **`swappiness=100`**:积极使用Swap 2. **解决内存泄漏问题** ```bash top -o %MEM # 按内存排序进程 ps aux --sort=-%mem | head # 显示内存消耗TOP10 ``` - 定位高内存进程:如Java应用可调整JVM堆大小,MySQL检查`innodb_buffer_pool_size`。 3. **物理内存升级** - 若物理内存长期使用率 >80%,扩容内存是终极方案。 --- ### **四、预防性监控** ```bash # 添加cron任务定期检查 */5 * * * * [ $(free | awk '/Swap/{print $4}') -lt 524288 ] && mail -s "SWAP WARNING" admin@example.com ``` - 工具推荐:`sar`、`Prometheus+Grafana`监控Swap趋势。 --- ### **典型场景分析** | **现象** | **原因** | **解决方案** | |------------------------|--------------------------|--------------------------| | Swap频繁写入(`so`高) | 物理内存不足 | 扩容内存或优化应用 | | Swap使用满但内存有空余 | `swappiness`值过高 | 调低至10-30 | | 特定进程占满Swap | 内存泄漏/配置错误 | 重启进程或调整资源限制 | > **关键原则**:Swap是内存不足的**应急手段**,非性能优化方案。数据库服务器等低延迟场景应尽量避免Swap[^3]。 --- **相关问题** 1. 如何区分Swap耗尽是因内存不足还是配置不当? 2. 在Kubernetes集群中如何预防Pod导致Swap耗尽? 3. 使用ZRAM替代传统Swap有何优缺点? 4. 为什么云服务器默认不启用Swap?如何安全启用? [^1]: Swap空间耗尽将导致系统卡顿甚至崩溃,尤其在IO密集型场景 [^2]: Swap仅在物理内存不足时启用,存储非活跃进程数据 [^3]: `swappiness`参数控制Swap使用倾向,直接影响性能 [^4]: 通过dd创建Swap文件可快速扩容,但需确保存储空间充足
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值