以下内容均来自个人笔记并重新梳理,如有错误欢迎指正!如果对您有帮助,烦请点赞、关注、转发、订阅专栏!欢迎扫码关注个人公众号,不定期推送热点文章!
本文已在 CSDN、知乎等平台陆续收到好评反馈,文中方法经多位小伙伴亲测有效,并且同样适用于欧拉系统。
笔者承诺本文永不设置 VIP 可读,供大家免费参考!欢迎大家转发起来,让更多需要的人看到!
如果本文确实可以帮到大家,请点赞、关注,感谢支持和鼓励!
一、背景回顾
【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(即 2^30,笔者猜测由于系统特性或存在 BUG,Kylin V10 与 其他操作系统对应的 infinity 换算方式不同),因此问题的解决方法也可以如下:
编辑对应的 docker.service 文件,修改如下:
LimitNOFILE=1048576
保存退出后执行
systemctl daemon-reload && systemctl restart docker
四、写在最后
本文介绍的解决方法可以作为一种通用方案使用,以规避 MySQL 以外的其他容器出现相同问题。
当然在具体实践中,如果遇到无法修改 LimitNOFILE 的情况(如实施交付时无权接触和修改客户环境的 docker.service 文件),还是可以使用之前的解决方法作为备用方案。