docker容器具有太大的文件描述符限制(ulimit -n)
我试图弄清楚为什么容器显示了一个非常大的打开文件描述符的限制:在主机上：
bld@nos 14:27:20 0 ~/dev/ (master)
$ ulimit -Hn
4096
bld@nos 14:27:32 0 ~/dev/ (master)
$ ulimit -n
4096主机上的根用户具有以下限制：
# ulimit -Hn
524288
# ulimit -n
1024运行刚刚构建的centos7映像：
bld@nos 14:27:35 0 ~/dev/ (master)
$ docker run --rm -ti -e -v -v -v bld:centos7 /bin/bash
[root@6d912cda1731 stingasrc]# ulimit -n
1073741816运行为非根的docker run -u "$(id -u):$(id -g)" --rm -ti -e -v -v -v bld:centos7 /bin/bash显示相同的结果。
主要问题是容器中的进程生成新线程，这些线程遍历最大文件复制器并关闭()它们--这需要.有一段时间，超过10亿个描述符。
虽然我知道-ulimit标志可以传递给码头运行，但我想知道：
在运行此容器时如何以及为什么应用1073741816的ulimit -n ?是否存在系统范围的设置?
回答 2
Stack Overflow用户
发布于 2022-04-25 11:14:05
非常感谢你打开这个。我正在处理我自己的问题，这使我朝着正确的方向前进。
我的dnsmasq容器做的正是The main issue is processes within the container spawns new threads that iterates through the max filedescriptors and close() them - which takes ... a while, for over a billion descriptors.：https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2020q1/013821.html
为了克服这一切我做了
# cat /etc/docker/daemon.json
{
"default-ulimits": {
"nofile": {
"Name": "nofile",
"Hard": 1024,
"Soft": 1024
},
"nproc": {
"Name": "nproc",
"Soft": 65536,
"Hard": 65536
}
}
}以及发生变化的sudo systemctl restart docker。
Stack Overflow用户
发布于 2022-04-11 13:31:20
Docker和Linux在调整所有这些cgroup和限制内容方面有着悠久的历史。
当init或systemd醒来时，内核执行第一个ulimit设置。
然后，对接引擎启动并强制systemd覆盖系统设置。如果您检查/usr/lib/systemd/system/docker.service并将nofile设置为无穷大，则可能会导致问题。有一些承诺将值更改为合理的值，然后返回到无穷大。这是为什么，但有时很难一次提供方便的处理和所有的使用程序。
码头命令--ulimit <type>=<soft>:<hard>正在给/etc/security/limits.conf或/etc/security/limits.d/...conf写信。用于文件描述符type = nofile。这也适用于/etc/docker/daemon.json，并覆盖以前创建的设置。
因此，对于ppl深入研究(显然您是其中之一)，最好在docker run或docker-compose.yml中将所有这些东西(所有这些限制)设置为对您的用例有意义的值。
(如果出了什么问题，明天可能会用Linux检查一下。)
编辑(忘记回答你的问题)：更新的内核将nofile设置为1073741816，也许也是centOS7。我认为(但不知道)主机上的限制设置不会移交给容器，引擎只是为在主机上运行容器的用户设置它们。因此，尝试在容器中单独设置nofile (例如编辑limits.conf)。
https://stackoverflow.com/questions/71828013
复制相似问题
腾讯云开发者
