以下内容均来自个人笔记并重新梳理,如有错误欢迎指正!
如果对您有帮助,烦请点赞、关注、转发!如果您有其他想要了解的,欢迎私信联系我~
背景回顾
【Docker】Kylin V10 下 MySQL 容器内存占用异常的解决方法 一文中提到的问题虽然解决了,但是笔者因为一个疑问决定继续深入挖掘,最终找到了问题的根因,本文将作为前文的延续进行说明。
疑问是啥
细心的读者会发现,【Docker】Kylin V10 下 MySQL 容器内存占用异常的解决方法 中「解决取值问题」部分,实测同一操作系统下主机与容器的 open files 参数取值居然也不一致,笔者一直很困惑容器的 open files 取值为何与主机不一致,这个取值又是从哪里来的?
原因是它
笔者查阅资料后得知,Linux 系统通过 /etc/security/limits.conf 来限制打开文件的数量(nofile),并对应 ulimit -a 中 open files 的值。
而 Docker 对打开文件数量(nofile)的限制与 Linux 系统的限制则是完全隔离的!
Docker 守护进程通过 docker.service 文件的 LimitNOFILE 参数限制容器的 open files,笔者在安装 Docker 时使用了 LimitNOFILE=infinity 这个默认配置,导致 Kylin V10 下容器取值为 1073741816(笔者猜测由于系统特性,Kylin V10 与 其他操作系统对应的 infinity 换算方式不同),因此问题的解决方法也可以如下:
编辑对应的 docker.service 文件,修改如下:
LimitNOFILE=1048576
保存退出后执行
systemctl daemon-reload && systemctl restart docker
写在最后
本文介绍的解决方法可以作为一种通用方案使用,以规避 MySQL 以外的其他容器出现相同问题。
当然在具体实践中,如果遇到无法修改 LimitNOFILE 的情况(如实施交付时无权接触和修改客户环境的 docker.service 文件),还是可以使用之前的解决方法作为备用方案。