OOM就一定要启用swap？

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

swap是什么

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

查看swap 的常见指令

显示swap分区大小

free -m 

此时数字显示的单位MBi

查看swappiness值

cat /proc/sys/vm/swappiness

改变当前值

 sudo sysctl vm.swappiness=0

使其生效

  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

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

列出系统中虚拟内存交换最大的进程，以及它们的名称和 PID（默认前十行）

for file in /proc/*/status ; do awk '/VmSwap|Name|^Pid/{printf $2 " " $3}END{ print ""}' $file; done | sort -k 3 -n -r | head

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