一、背景

做redis压测过程中，发现paas环境的redis被OOMKill老是不断重启

Pod日志：

二、排查方案：

1. 可能是数据量超出了限制的大小，检查数据目录大小

2. 查看是否是内存溢出

开始排查

2.1 排查数据量（查看数据目录大小是否超过limit限制）

limit限制为64G 查到数据目录占用很少 忽略此问题

2.2 查看pod详情发现问题

为了更准确的定位问题，查看是否是内存泄露问题，查看系统参数（正常是没有输出）

确定是由于压测导致的Cgroup内存泄露问题
定位原因以后解决问题 ：处理内存泄露问题（试了三个方案才得以解决）

三、解决过程

方案一：（修改grub文件）

1. 修改/etc/default/grub 为：
   GRUB_CMDLINE_LINUX=“crashkernel=auto net.ifnames=0 biosdevname=0 intel_pstate=disable cgroup.memory=nokmem”
   是追加 GRUB_CMDLINE_LINUX=“console=tty0 console=ttyS0 crashkernel=512M-2G:128M,2G:512M rd.lvm.lv=bel/root rhgb quiet cgroup.memory=nokmem” 把 cgroup.memory=nokmem
   追加到最后即可
2. 生成配置： /usr/sbin/grub2-mkconfig -o /boot/grub2/grub.cfg
3. 重启机器： reboot
4. 验证： cat /sys/fs/cgroup/memory/kubepods/burstable/pod*/*/memory.kmem.slabinfo 无输出即可。
5. x版本cgroup.memory存在bug，docker或其他使用cgroup.memory中kmem功能的应用会造成slab内存泄漏 部分系统可以通过升级到4.x的修复版本来解决，或者通过 cgroup.memory=nokmem 启动项来规避。 部分系统不支持cgroup.memory=nokmem 启动项，可以通过 cgroup_disable=memory 启动项来规避。（此方案解决部分机器，并未全部解决）

方案二：（升级内核、Iaas建议）
由于服务器均为多系统，可以进行此操作

既然是 3.x 的问题，直接升级内核到 5.x 及以上即可，内核问题解释： https://github.com/torvalds/linux/commit/d6e0b7fa11862433773d986b5f995ffdf47ce672 https://support.mesosphere.com/s/article/Critical-Issue-KMEM-MSPH-2018-0006
这种方式的缺点是： 需要升级所有节点，节点重启的话已有 pod 肯定要漂移，如果节点规模很大，这个升级操作会很繁琐，业务部门也会有意见，要事先沟通。 这个问题归根结底是软件兼容问题，3.x 自己都说了不成熟，不建议你使用该特性，k8s、docker却 还要开启这个属性。（此方案并不奏效）

方案三：（grubby在线修改内核参数）
查看当前内核版本

--update-kernel 为当前内核版本文件
grubby --args=cgroup.memory=nokmem --update-kernel=/boot/vmlinuz-3.10.0-1160.el7.x86_64

重启主机 查看系统参数 （显示正常）

查看pod正常运行

附加知识点：（内存buff占用清理 -hcache）

wget https://silenceshell-1255345740.cos.ap-shanghai.myqcloud.com/hcache
chmod 755 hcache && mv hcache /usr/local/bin/
hcache --top 10

查看内存 free -h

buffers: 用于块设备数据缓冲，记录文件系统metadata（目录，权限，属性等)
cached: 用于文件内容的缓冲

分别查看

清理缓存

1. 仅清除页面缓存（PageCache）
2. sync; echo 1 > /proc/sys/vm/drop_caches
3. 清除目录项和inode
4. # sync; echo 2 > /proc/sys/vm/drop_caches
5. 清除页面缓存，目录项和inode
6. # sync; echo 3 > /proc/sys/vm/drop_caches

清理交换空间：swapoff -a && swapon -a