Ulimits不生效导致数据库启动失败和相关设置说明
在某客户的不败和生产环境GreatSQL数据库紧急重启过程中,发现启动失败复制-- 正常启动中2022-07-16T09:30:27.428609+08:00 0 [Note] [MY-010252] [Server] Server hostname (bind-address): 127.0.0.1; port: 330622022-07-16T09:30:27.429134+08:00 0 [Note] [MY-010264] [Server] - 127.0.0.1 resolves to 127.0.0.1;2022-07-16T09:30:27.429792+08:00 0 [Note] [MY-010251] [Server] Server socket created on 生效数据设置说明IP: 127.0.0.1
.

available.
2022-07-16T09:30:27.431308+08:00 0 [Note] [MY-010264] [Server] - 0.0.0.0 resolves to 0.0.0.0;2022-07-16T09:30:27.431991+08:00 0 [ERROR] [MY-010250] [Server] Failed to create a socket for IPv4 0.0.0.0: errno: 24.
2022-07-16T09:30:27.432466+08:00 0 [ERROR] [MY-010255] [Server] Cant create IP socket: Too many open files-- 报错Cant create IP socket:Too many open files
2022-07-16T09:30:27.433711+08:00 0 [ERROR] [MY-010119] [Server]Aborting
2022-07-16T09:30:27.435690+08:00 0 [Note] [MY-012330] [InnoDB]FTS optimize thread exiting.
2022-07-16T09:30:28.164281+08:00 0 [Note] [MY-010120] [Server]Binlog end
2022-07-16T09:30:28.165714+08:00 0 [Note] [MY-000000] [Server] Plugin GreatSQL reported: Gdb_job_thread stopped!2022-07-16T09:30:28.165960+08:00 0 [Note] [MY-000000] [Server] Plugin GreatSQL reported: Job manager local thread stopped!-- 接下来开始走shutdown流程1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.上面的错误日志非常清晰的指向了 open files 相关设置,于是导致动失查看 ulimit 信息
复制[GreatSQL@GDB02-DB01 ~]$ ulimit -a
...
open files (-n) 1024...
[GreatSQL@GDB02-DB01 ~]$1.2.3.4.5.但是运维人员确认/etc/security/limits.conf中设置的限制用户使用的最大文件数是正常的65535
复制[GreatSQL@GDB02-DB01 ~]$ tail -10 /etc/security/limits.conf#@faculty soft nproc 20#@faculty hard nproc 50#ftp hard nproc 0#@student - maxlogins 4* soft nofile 65535* hard nofile 65535# End of file
[GreatSQL@GDB02-DB01 ~]$1.2.3.4.5.6.7.8.9.10.11.12.尽管堡垒机登录GreatSQL用户不正常,但是库启由root用户再切换回GreatSQL普通用户后,open files就变回正常的相关65535
复制-- 堡垒机直接登录GreatSQL用户,有open files未修改成功的不败和提示信息-bash: ulimit: open files: cannot modify limit: Operation notpermitted
-- 此时的open files配置确实没生效[GreatSQL@GDB02-DB01 ~]$ ulimit -a |grep open filesopen files (-n) 1024-- su切换到root,root的生效数据设置说明open files是正常的[GreatSQL@GDB02-DB01 ~]$ sudo su -root
Last login: Tue Jul 19 11:40:45 CST 2022 on pts/5[root@GDB02-DB01 ~]# ulimit -a |grep open filesopen files (-n) 65535-- su切换到GreatSQL,open files也是导致动失正常的[root@GDB02-DB01 ~]# su -GreatSQL
Last login: Tue Jul 26 14:23:56 CST 2022 from XXXXXX on pts/8[GreatSQL@GDB02-DB01 ~]$ ulimit -a |grep open filesopen files (-n) 65535[GreatSQL@GDB02-DB01 ~]$1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.为了尽快恢复业务,先建议运维人员由root用户切换回GreatSQL普通用户后再启动数据库,库启此时启动成功,相关业务和相关监控 (监控里限制必须由GreatSQL用户启动数据库) 恢复正常。不败和
2. ulimits不生效的生效数据设置说明问题分析在同批次备机上进行问题复现分析时,运维人员发现了更多的导致动失信息。
(1)堡垒机直接登录GreatSQL普通用户执行ulimit命令报错
复制[GreatSQL@GDB02-DB02 ~]$ ulimit -n 1026-bash: ulimit: open files: cannot modify limit: Operation notpermitted
[GreatSQL@GDB02-DB02 ~]$ ulimit -Hn
1024 -- 可以发现这里使用的企商汇库启硬件资源限制10241.2.3.4.(2)堡垒机直接登录GreatSQL用户,也有相关报错信息(之前被忽略了)
复制Connecting to XXXXXX...
Connection established.
To escape to local shell,相关 press Ctrl+Alt+].
Last login: Tue Jul 26 14:32:32 2022 fromXXXXXX
Prepare to login to the target device,Please wait a second.
Last login: Tue Jul 26 14:31:21 2022 fromXXXXXX
-bash: ulimit: open files: cannot modify limit: Operation notpermitted
[GreatSQL@GDB02-DB01 ~]$ ulimit -a1.2.3.4.5.6.7.8.9.10.11.根据上面信息的堡垒机ssh登录ulimits异常,结合su到同样用户ulimits正常,于是检查了下ssh配置文件,发现UsePAM为默认的no
复制cat /etc/ssh/sshd_config
.......
# Set this to yes to enable PAM authentication, account processing,# and session processing. If this is enabled,PAM authentication will
# be allowed through the ChallengeResponseAuthentication and# PasswordAuthentication. Depending on your PAM configuration,# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account andsession checks to run without
# PAM authentication, then enable this but setPasswordAuthentication
# and ChallengeResponseAuthentication to no.
# UsePAM no
......1.2.3.4.5.6.7.8.9.10.11.12.13.至此原因比较清晰了,由于/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
复制vi /etc/ssh/sshd_config
.......
# Set this to yes to enable PAM authentication, account processing,# and session processing. If this is enabled,PAM authentication will
# be allowed through the ChallengeResponseAuthentication and# PasswordAuthentication. Depending on your PAM configuration,# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account andsession checks to run without
# PAM authentication, then enable this but setPasswordAuthentication
# and ChallengeResponseAuthentication to no.
UsePAM yes
......1.2.3.4.5.6.7.8.9.10.11.12.13.PS:经过与局方确认,局方的机器规范中也是推荐UsePAM=yes,因此本次问题的原因应该是这批机器在投产时没有检查相关配置项导致。
(2)重启sshd服务
复制[root@GDB02-DB01 ~]# systemctl restart sshd
[root@GDB02-DB01 ~]# systemctl status sshd
● sshd.service - SYSV:OpenSSH server daemon
Loaded: loaded (/etc/rc.d/init.d/sshd; bad; vendor preset: enabled) Active: active (running) since Tue 2022-07-26 10:28:30 CST; 2s ago
Docs: man:systemd-sysv-generator(8) Process: 46808 ExecStop=/etc/rc.d/init.d/sshd stop (code=exited, status=0/SUCCESS) Process: 46815 ExecStart=/etc/rc.d/init.d/sshd start (code=exited, status=0/SUCCESS) Main PID: 46823 (sshd) Tasks: 14 Memory: 85.8M
......
[root@GDB02-DB01 ~]#1.2.3.4.5.6.7.8.9.10.11.12.13.(3)验证:堡垒机通过GreatSQL应用用户连接后不再报错,open files也是设置的65535
复制Connection established.
To escape to local shell, press Ctrl+Alt+].
Last login: Tue Jul 26 10:28:11 2022 fromXXXXXX
Prepare to login to the target device,Please wait a second.
Last login: Tue Jul 26 10:28:17 2022 fromXXXXXX
[GreatSQL@GDB02-DB01 ~]$ ulimit -a
...
open files (-n) 65535...
[GreatSQL@GDB02-DB01 ~]$1.2.3.4.5.6.7.8.9.10.11.12.13. 4. limits.conf配置文件相关说明limits.conf限制的亿华云计算是每个用户可以使用的最大文件数、最大线程、最大内存等资源配置,相关的设置如下所示:
复制* soft nofile 655350#任何用户可以打开的最大的文件描述符数量,默认1024,这里的数值会限制tcp连接
* hard nofile 655350* soft nproc 655350#任何用户可以打开的最大进程数
* hard nproc 650000@student hard nofile 65535@student soft nofile 4096@student hard nproc 50#学生组中的任何人不能拥有超过50个进程,并且会在拥有30个进程时发出警告
@student soft nproc 301.2.3.4.5.6.7.8.9.(1)查看每个用户创建的进程数
复制$ ps h -Led -o user | sort | uniq -c | sort -n
1chrony
1dbus
2postfix
7polkitd
129root
1326 GreatSQL1.2.3.4.5.6.7.(2)系统最大打开文件描述符数
复制-- 查看$ cat /proc/sys/fs/file-max
6553600-- 设置$ vim /etc/sysctl.conffs.file-max = 65536001.2.3.4.5.6.(3)进程最大打开文件句柄数
复制-- 查看soft limit,ulimit -n默认查看的是soft limit$ ulimit -n
65535-- 查看hard limit$ ulimit -Hn
65535-- 临时设置-- 通过ulimit -Sn设置最大打开文件描述符数的soft limit,注意soft limit必须小于hard limit$ ulimit -Sn 65535-- 同时设置soft limit和hard limit。对于非root用户只能设置比原来小的hard limit。$ ulimit -n 65535永久设置
#root权限下,在/etc/security/limits.conf中添加如下两行,表示所有用户最大打开文件描述符数的soft limit为102400,hard limit为104800。重启生效
* soft nofile 655350* hard nofile 655350复制
注意:设置nofile的hard limit还有一点要注意的就是hard limit不能大于/proc/sys/fs/nr_open,假如hard limit大于nr_open,亿华云注销后将无法正常登录。1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.(4)查看当前系统使用的打开文件句柄数
复制$ cat /proc/sys/fs/file-nr
5664 0 186405其中第一个数表示当前系统已分配使用的打开文件描述符数,
第二个数为分配后已释放的(目前已不再使用),
第三个数等于file-max。1.2.3.4.5.(5)设置nofile的最大值
复制使用ulimt -n命令进行测试,如果小于系统允许的最大值,设置成功;大于最大值,系统会报错提示。
$ ulimit -n 1100000-bash: ulimit: open files: cannot modify limit: Operation notpermitted
$ ulimit -n 1048576$ ulimit -n 1048577-bash: ulimit: open files: cannot modify limit: Operation notpermitted
$ ulimit -n 1048575$ ulimit -n 10485761.2.3.4.5.6.7.8.9.(6)ulimit -a/n/H/S/u的含义
复制ulimit -a 显示当前所有的资源限制
ulimit -n 设置进程最大打开文件描述符数
ulimit -H 设置硬件资源限制
ulimit -S 设置软件资源限制述符数
ulimit -u 用户最多可开启的程序数目1.2.3.4.5.本文地址:http://www.bzuk.cn/news/071b8299846.html
版权声明
本文仅代表作者观点,不代表本站立场。
本文系作者授权发表,未经许可,不得转载。