内容简介:可直接点击上方蓝字(网易游戏运维平台)关注我们,获一手游戏运维方案
可直接点击上方蓝字
(网易游戏运维平台)
关注我们,获一手游戏运维方案
igi
网易游戏运维专家, 10 年运维老司机, 负责网易游戏私有云平台的运维工作, 专注于运维技术能力的深入打磨, 专治运维界各类疑难杂症, 拥有强大的故障分析能力及丰富的故障解决经验 .
多年来,我们陆续有业务遇到 ulimit 的各类衍生问题,无论是在 SysVinit 时代,还是 Systemd 时代,甚至在容器环境中,虽然表现不同,但根本原因还是 ulimit 问题。本文会讲下我们因 ulimit 设置遇到的各种问题,并给大家深入浅出的点透 ulimit 这一知识点,愿大家新年不踩旧坑,线上无病无灾。
SysVinit 下的 ulimit 如何生效
早年在 SysVinit 年代,我们就明白 ulimit 需要特别设置才能避免踩坑,使用的是如下的方法来设置 SysVinit 下 1 号进程的子进程的 limit。
-
该配置文件只适用于 SysVinit,并且需要重启生效
它调整的 不是 1 号进程本身的 limit, 而是会改变 1 号进程执行 /etc/inittab 时 fork 出来的子进程的 limit,比如说 sshd 的 limit , 我们可以通过以下方法来验证调整是否生效
Systemd 下的 ulimit 如何生效
后来 Systemd 开始流行了,Debian 也开始切换到 Systemd。而 Systemd 的 limit 就不在 /etc/initscript 文件中定义了,它是在 /etc/systemd/system.conf 配置中。
-
该配置需要重启生效
-
与 SysVinit 不同,Systemd 这个配置会影响 1 号进程本身的 limit,所以可以直接检查 /proc/1/limits 来判断是否配置正确
疑难杂症
1. 只有 /etc/initscript 是不够的,很多应用会使用 PAM (/etc/security/limits.conf)
大约在 2010 年的时候,我们线上遇到一起故障,就是用户的 crontab 中启动的任务,遇到了 max open file 不足的故障,排查下来,我们发现 cron 会使用了 PAM 模块,它会读取 /etc/security/limits.conf 中的设置来覆盖原本的 limit 值,这部分引用定义在 /etc/pam.d/cron 中。
解决方案很简单,就是在 /etc/security/limits.conf 中定义相关的 limit 值
-
使用 PAM 的应用很多,比如 su,sudo,cron,login,sshd 等,sshd 的情况比较特别,它的 UsePAM 参数默认值为 no。
2. 在 Debian 系统中, /etc/security/limits.conf 中的 * 号通配并不匹配 root 用户
在后续的工作中,我们遇到一起比较特别的故障,背景是有台机器 sshd 应用故障了,机房同事通过 console 登录机器重启 sshd,而后续我们通过 ssh 登录来启动的应用都是非优化后的 limit 值。排查出来的原因是 Debian 系统中,/etc/security/limits.conf 中的 * 号通配并不匹配 root 用户,机房同事通过 console 口登录 root 用户,会导致登录后的会话是默认的 limit 值,以该会话来重启 sshd 使得 sshd 继承了该会话有问题的 limit 值,进而影响后续从 ssh 登录来启动的应用,我们的游戏业务,多数以这种模式来跑起来的。
那么为什么说它特别,除了故障本身是一环扣一环,还因为 * 号通配并不匹配 root 用户的行为,是 Debian 系列特有的,我们测试了 Centos 并看了 Centos 的文档,* 号是可以匹配 root 用户,但在 Debian 系统的 manpage 中,就有这么特别的一句
最终我们修正后的 /etc/security/limits.conf 配置如下
TIPS:看文档一定要看官方文档,别人的文章、其它发行版的文档,不一定是能适用的。
4. 某些 Systemd 版本会导致 max open file 在设置为 infinity 时只有 65536
有一次,在一台 Debian8 的机器上,发现了这样一个问题,在 Systemd 下面,设置了 DefaultLimitNOFILE = infinity
, 但 1 号进程及其它子进程 max open file 只有 65536,而非预期的等于 fs.nr_open 默认值 1048576
。最后排查出原因,其实是 Systemd 的一个 bug(https://github.com/systemd/systemd/commit/6385cb31ef443be3e0d6da5ea62a267a49174688)
解决方案就是直接定义明确的 DefaultLimitNOFILE 值或是升级到 Systemd 新版本。
5. 不同 PAM 版本会有不同的默认 limit 值处理逻辑
去年我们线上的容器业务 (胖容器),也遇到 ulimit 相关的故障。业务从 Debian8 容器升级到 Debian9 容器后,发现 soft nofile limit 值不正确导致了问题。表现为在容器中 su 后,Debian9 容器出现了未优化的 soft nofile limit 值,Debian8 容器则可以正常地应用到宿主的 soft nofile limit 值。排查发现,我们所使用的容器镜像并没有打包 /etc/security/limits.conf 文件(官方镜像也没有)。在没有配置 /etc/security/limits.conf 文件的情况下,Debian8 下的 PAM 版本,会直接使用容器的 1 号进程的 soft nofile limit 值;而 Debian 9 的 PAM 版本,则会使用 FD_SETSIZE 宏定义中的值,相当于在编译阶段就确定好的默认值,默认为 1024。
解决方案很简单,就是打包上正确的 /etc/security/limits.conf 文件,即使 Debian8 也打包上,方便统一管理。
相关变更及 bug:
-
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783105
-
https://metadata.ftp-master.debian.org/changelogs//main/p/pam/pam_1.3.1-5_changelog
排查要点
每个进程的 limit 初始值来源,要么来自它的父进程,要么是来自 PAM,其中 PAM 的优先级更高,只要抓住这两点,问题都不复杂。
常见问题
1. 如何确认一个应用有没有使用了 PAM
可以查一下 /etc/pam.d/ 下面的文件,有没有对应的应用配置
2. 如何确认当前系统是 SysVinit 还是 Systemd
查一下 /sbin/init 的信息,可以确认出来
-
SysVinit:
-
Systemd:
-
Upstart:
3. 如何在线修改一个进程的 limit 值
例如当我们发现 sshd 的 max open file 配置有问题,但我们又不想重启该服务,可以使用 prlimit 命令来在线调整
#当前 & nbsp;ssh 登录后的 & nbsp;max open file 异常 igi@mbp:~$ ssh myhost igi@hostname:~$ ulimit -n -S 1024 igi@hostname:~$ ulimit -n -H 1024 igi@hostname:~$ grep 'Max open files' /proc/`pgrep -f '/usr/sbin/sshd'`/limits Max open files 1024 1024 files
#在线调整 & nbsp;max open file root@hostname:~# pgrep -f '/usr/sbin/sshd' 523 root@hostname:~# prlimit --pid=523 --nofile=1000000
#重新登录检查 igi@mbp:~$ ssh myhost igi@hostname:~$ ulimit -n -S 1000000 igi@hostname:~$ ulimit -n -H 1000000 igi@hostname:~$ su Password: root@hostname:~# pgrep -f '/usr/sbin/sshd' 523 root@hostname:~# prlimit --pid=523 | grep NOFILE NOFILE max number of open files 1000000 1000000
结束语
万变不离其宗,ulimit 的问题虽然有各种表现形式,只要掌握其关键点,就再也不是疑难问题。
每个进程的 limit 初始值来源,要么来自它的父进程,要么是来自 PAM,其中 PAM 的优先级更高。
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:- TypeScript 疑难杂症
- 话说 Kubernetes 网络疑难杂症
- TCP协议疑难杂症全景解析
- Autowired无法正常注入的疑难杂症
- 十八问,认识Python序列,解决疑难杂症!
- PHP 疑难杂症:解决守护进程时 Redis 假死
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
大象无形:虚幻引擎程序设计浅析
罗丁力、张三 / 电子工业出版社 / 2017-4 / 65
《大象无形:虚幻引擎程序设计浅析》以两位作者本人在使用虚幻引擎过程中的实际经历为参考,包括三大部分:使用C++语言进行游戏性编程、了解虚幻引擎本身底层结构与渲染结构、编写插件扩展虚幻引擎。提供了不同于官方文档内容的虚幻引擎相关细节和有效实践。有助于读者一窥虚幻引擎本身设计的精妙之处,并能学习到定制虚幻引擎所需的基础知识,实现对其的按需定制。 《大象无形:虚幻引擎程序设计浅析》适合初步了解虚幻......一起来看看 《大象无形:虚幻引擎程序设计浅析》 这本书的介绍吧!