
ulimits不生效导致数据库启动失败和相关设置说明
1. 问题描述
在某客户的生产环境GreatSQL数据库紧急重启过程中,发现启动失败
上面的错误日志非常清晰的指向了 open files 相关设置,于是查看 ulimit 信息
但是运维人员确认/etc/security/limits.conf中设置的限制用户使用的最大文件数是正常的65535
尽管堡垒机登录GreatSQL用户不正常,但是由root用户再切换回GreatSQL普通用户后,open files就变回正常的65535
为了尽快恢复业务,先建议运维人员由root用户切换回GreatSQL普通用户后再启动数据库,此时启动成功,业务和相关监控 (监控里限制必须由GreatSQL用户启动数据库) 恢复正常。
2. ulimits不生效的问题分析
在同批次备机上进行问题复现分析时,运维人员发现了更多的信息。
1.堡垒机直接登录GreatSQL普通用户执行ulimit命令报错
2.堡垒机直接登录GreatSQL用户,也有相关报错信息(之前被忽略了)
根据上面信息的堡垒机ssh登录ulimits异常,结合su到同样用户ulimits正常,于是检查了下ssh配置文件,发现UsePAM为默认的no
至此原因比较清晰了,由于/etc/security/limits.conf 文件实际是 Linux PAM(插入式认证模块,Pluggable Authentication Modules)中 pam_limits.so 的配置文件,而没有使用 PAM 模块场景下,自然也就没有读取到 /etc/security/limits.conf 的内容。
而 su 进行用户切换时使用的是终端TTY登陆(默认使用PAM模块),导致堡垒机的GreatSQL切换到root、再su GreatSQL后limits相关设置正常。
3. 解决方法
1.修改ssh配置文件,UsePAM=yes
PS:经过与局方确认,局方的机器规范中也是推荐UsePAM=yes,因此本次问题的原因应该是这批机器在投产时没有检查相关配置项导致。
2.重启sshd服务
3.验证:堡垒机通过GreatSQL应用用户连接后不再报错,open files也是设置的65535
4. limits.conf配置文件相关说明
limits.conf限制的是每个用户可以使用的最大文件数、最大线程、最大内存等资源配置,相关的设置如下所示:
1.查看每个用户创建的进程数
2.系统最大打开文件描述符数
3.进程最大打开文件句柄数
4.查看当前系统使用的打开文件句柄数
5.设置nofile的最大值
6.ulimit -a/n/H/S/u的含义
Enjoy GreatSQL :)
文章转载自公众号:GreatSQL社区
