以下内容均来自个人笔记并重新梳理，如有错误欢迎指正！
如果对您有帮助，烦请点赞、关注、转发！如果您有其他想要了解的，欢迎私信联系我～
背景回顾
【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 换算方式不同），因此问题的解决方法也可以如下：
代码语言：javascript复制编辑对应的 docker.service 文件，修改如下：
LimitNOFILE=1048576
保存退出后执行
systemctl daemon-reload && systemctl restart docker写在最后
本文介绍的解决方法可以作为一种通用方案使用，以规避 MySQL 以外的其他容器出现相同问题。
当然在具体实践中，如果遇到无法修改 LimitNOFILE 的情况（如实施交付时无权接触和修改客户环境的 docker.service 文件），还是可以使用之前的解决方法作为备用方案。
