记一次oom_kill的排查

在近期的开发中出现过：

        因算法进程占用最高的内存而在系统发生oom时被kill，通过排查，发现主要原因不在于应用程序，虽然应用有些迹象出现内存泄露，但泄露很小或因系统内存回收延时，真正的原因出现于系统的交换分区的配置上：

系统情况：nx板子，4~6核，8G内存，ssd，128G，ubuntu系统

应用情况：rabbitmq，python、qt做的界面系统，算法

外设情况：连接布控球（摄像头）

网络情况：ap-wifi，eth0预留，eth1连接布控球

内存情况：物理内存：8G , swap分区：4个zram[0-4] 3.8G*4 = 15.2G 总内存约23G

使用内存情况：主要是算法需要12G以上的内存，所以需要用上ssd的空间做交换分区，用zram？zswap？zswap？

出现问题的情况：当算法运行到8G+5G（swap)时，系统就out of memory，触发了oom-kill

分析及解决方案：

1、使用zram在这个需求上是错误的，zram可以理解为通过占用一定的内存进行压缩（lzo,lz4压缩，压缩率应该是3:1），变相增加内存的量，优点，速度快，比硬盘的swap应该是快多了，所以不管zram设定多大，在这个8G的设备上，最大的内存量=8G~16G，23G的总内存应该是假，才会当算法跑到8+5G时出问题了，当测试程序跑到8+7G也出问题了。

2、解决方案，此场景下可能用zswap+swap是最合适的，比swap快。

由于系统方案已定，不能修正，所以临时以下给出swap的方案，用硬盘文件做16Gswap：

swaps="/tmp/swaps"
sw_mem=$((16*1024*1024*1024))
if [ ! -f $swaps ]; then
  sudo swapoff -a
  sudo fallocate -l $sw_mem $swaps
  sudo chmod 600 $swaps
  sudo mkswap $swaps
  sudo swapon -p 10 $swaps
fi
exit 0