[转]深入理解Docker ulimit(docker容器启动报错library initialization failed - unable to allocate file descriptor table - out of memory问题解决)

原文地址:深入理解Docker ulimit - DockOne.io

【编者的话】Docker大规模应用后,如果你没踩过坑,说出去肯定没人信。昨天就遇到一个ulimit的经典问题:业务Container内ulimit值太小,导致启动失败。ulimit问题,老生常谈,但是在不同的场景与环境,表现出来的灵异,往往需要一些深入的分析才能找到本因。本次问题就与OS版本,Docker版本及配置方法息息相关,我们来回顾一下。

问题

1. 背景

微博平台业务经过去年三节Docker化后,已稳定运行半年多了,由于采用的都是较保守的版本,虽然也踩过很多坑,但都在可控内。最近正与RD一起推进一个大项目,前提也是平台业务全Docker化,这部分已完成90%了。其基本信息如下:
1)OS版本:CentOS 6.5
2)JDK: 1.7.0_25 Tomcat: 7.0.42
3)Docker:1.3.2
4)Docker Registry:1.0
其中:正在也推进升级OS到CentOS 7,Docker到1.6.2。

2. 现象

本次出现的问题现象:当人工重启服务器后,再启动业务Container,发现启动失败,并且能够重现。

PS: 用运维系统做部署时并未发现此问题。

3. 重现

重现的主要条件为:
1)版本:OS(CentOS 6.5),Docker 1.3.2,Docker Daemon随开机启动而启动。
2)主机配置:ulimit设置为200000,配置在/etc/profile。
3)操作:手工reboot机器后,登录,启动业务容器,启动起来后,一会就失败。

4. 分析

1)服务器重启,此过程正常。
2)业务Container启动后不久失败,经分析为容器内ulimit不对,只获得默认的值:1024。后面会讲这个值为什么是1024。
3)重启Docker Daemon进程,再启动Container,发现一切正常。经查看容器内ulimit值为:主机设置的200000。

现象搞清楚后,且能重现,解决问题就很简单了,方法很多。后面细说。

5. 总结

一句话总结,当服务器重启后,Docker Daemon随之系统启动而启动,当启动Container时,因未获取到主机设置的ulimit值而导致启动后一会儿就失败了,重启Docker Deamon后解决(PS:这不是解决问题的方法,这只是瞎猫撞到死耗子)。

经典理论之ulimit

关于ulimit问题,我相信只要是做过SA,或者玩过服务器的RD都应该遇到过,各种现象,其理论依据其实很简单,大家可以参考@淘宝褚霸 博客的文章,有4篇,足够细致了。2013年时,我问过他一个问题,他还从源码角度去分析了,这种分享精神棒棒哒。这里就不再展开说了。

经典理论之Linux系统启动与环境变量加载顺序

1. Linux系统启动

这里就直接说CentOS(Redhat类)的启动过程:大家都知道目前Linux系统启动最常用的就是两种:init(SysVinit系)与Systemd系两大阵营,二者的对比可以参考此文。Systemd主要是CentOS 7及之后的版本采用,而之前的发行版均采用SysVinit系,而我们这次出现问题的是CentOS 6.5,也就是SysVinit系。下面来看下它的启动过程,参考图如下:
03114003_uwr7.jpg

具体过程:
1)加载BIOS的硬件信息,执行BIOS内置程序。
2)读取MBR(Master Boot Record)中Boot Loader中的引导信息。
3)加载内核Kernel boot到内存中。
4)内核开始执行/sbin/init,并加载/etc/inittab,执行rc.sysinit进行初始化。
5)启动核心的外挂模块/etc/modules.conf。
6)按照启动级别(服务器默认是3)执行/etc/rc.d/下运行脚本。即:
[guansheng@xx-xx-xx-yf-core rc3.d]# pwd
/etc/rc.d/rc3.d/

这个过程会把chkconfig --list中看到3级下on的服务全部启起来。
7)执行/bin/login程序。

到这里,你就可以看到登录的tty窗口了。

2. Linux环境变量加载顺序

对于环境变量加载顺序,各发行版本大同小异,这里也只说RedHat系的,其大致顺序如下:
--> /etc/profile     #全局环境变量,每个用户第一次登录时设置
-------->~/.bash_profile #用户级环境变量,每个用户第一次登录时设置
-------->~/.bash_login
-------->~/.profile 
-->~/.bashrc   #用户级环境变量,每个用户登录时设置,打开新Shell时也设置
-->/etc/bashrc
-->~/.bash_logout #用户级环境变量,退出时执行

规则:后面的配置文件继续前面的变量及shell设置,相同的被覆盖。

3. 理论参考之Docker ulimit

Docker在1.6版本及之后,才支持ulimit相关选项,看GitHub上,应该是有人提了PR,后来官方才支持的。 在1.6版本之前,Docker Container继承自Docker Daemon的ulimit设置。 参考文章见Docker blog 之ulimit部分

问题复盘

经过以上详细介绍及理论引导,其实对于问题复盘就很简单了,我们简要过一下重点:

1,由于我们人工重启服务器后,根据上面的启动过程可知,Docker Daemon在系统启动时已经起来了,此时在用户未登录的情况下,并不会读取我们设置的/etc/profile下的ulimit配置,所以Docker Daemon会以1024的值进行进程的启动。

2,那么后续创建的Container由于Docker版本为1.3.2,是继续自Docker Daemon的值,而造成在Container只能看到1024的ulimit值,而业务上依赖大量的mc、mcq、Redis、MySQL及HTTP等,自然1024不够用,而启动失败。

3,当用户登录后,重启Docker Daemon后,进程自然会能读取到该用户的环境变量,从而使ulimit设置为200000。之后再启动Container就再无问题了。

PS:复盘很简单吧,不过不理解上述原理,很多人还是一头雾水,至少我见到是这样。

新问题

探讨CentOS 7下的ulimit

1. 问题描述

当OS为CentOS 6.5,Docker为1.3.2版本情况下的问题理清后,想试试7,于是在7下依然部署了Docker 1.3.2,并进行测试,新问题来了,当主机(Host)上未进行设置时(即为默认1024),启动Container,发现Container内的ulimit是1048576。修改主机的ulimit,再重启Docker Daemon,启动Container,Container内还是1048576,好奇怪。

2. 分析

经过与同事一起看了下Docker源码,Daemon启动那部分,一下子就明朗了。可以看到,Docker Daemon针对不同的系统版本,其对ulimit的默认值设置大有差别。

1)CentOS 7 采用Systemd进行系统初始化,自动会调用Systemd下的启动脚本docker.service,其申明默认值如下:
[Service]
         ExecStart=/usr/bin/docker -d -H fd://
         MountFlags=slave
         LimitNOFILE=1048576
         LimitNPROC=1048576
         LimitCORE=infinity

2)CentOS 6的话,Docker Daemon启动,并未设置默认值。参考:sysvinit-redhat。
3)而对于Debian类的系统,尽然也设置了默认值为:1048576。参考

Docker 1.6版本对ulimit的设置:

在很多时候,对于单个容器来说,这样的ulimit实在是太高了。在Docker 1.6里,可以设置
1) 全局默认的ulimit:
docker -d --default-ulimit nproc=1024:2048
  docker -d --default-ulimit nofile=20480:40960 nproc=1024:2048

2)在启动容器时,单独对其ulimit进行设置:
docker run -d --ulimit nofile=20480:40960 nproc=1024:2048 容器名

这里有一篇介绍,可以加深你的理解。

对于Docker ulimit的灵活设置,这里还有一个理论需要注意:

1) Docker容器默认移除sys_resource(Linux能力),因而ulimit -n设置只能改小无法改大,改大会报错:ulimit: open files: cannot modify limit: Operation not permitted。
2) CentOS 7下docker run可以使用–privileged选项来不移除Linux能力,但Docker默认移除这个Linux能力肯定是有安全方面的考量,因此尽量别用该选项。
3) CentOS 6下要使用–privileged,Docker版本不能>=1.0.1,否则会报错;stat /dev/.udev/db/cpuid:cpu0: no such file or directory

解决

经过上面的讨论,相应把问题应该说清楚了,也解释清楚了。那么CentOS 6下,除了上述的手动重启Docker Daemon方法解决外,还有其他方法吗?答案是肯定的,有很多方法,这里简要说一种吧,思路类似。

即:若使用sysV服务,则在/etc/init.d/functions最开头添加一行:ulimit -u 204800 -HSn 204800
原理为:Docker服务启动脚本第一行会去执行它。
[guansheng@xx-xx-xx-yf-core ~]# ll /etc/rc.d/rc3.d/ |grep docker
lrwxrwxrwx  1 guansheng root  16 Jul  3 19:25 S95docker -> ../init.d/docker

网友建议:

1) @ARGV 指出,/etc/init.d/functions会被所有随系统启动的服务调用,建议直接设置在../init.d/docker启动脚本里,建议有效,感谢指正。不过,这个相当于去修改Docker Daemon的自启动脚本了。
2) @枯木-Linux,与之交流,发现最好的方案,还是直接修改 /etc/sysconfig/docker 配置文件。赞一个。

总结

白天出的问题,一个多小时把它理清并解决了,感觉还是蛮好的。深夜,头脑清醒,就想写篇长微博分享给大家,问题虽不难,但崇尚分享精神总是很好的。
posted @ 2022-10-08 16:42  dirgo  阅读(6031)  评论(0编辑  收藏  举报