故障案例 | lsof是怎么"影响"MySQL计算打开文件句柄数的
欢迎来到 GreatSQL社区分享的MySQL技术文章,如有疑问或想学习的内容,可以在下方评论区留言,看到后会进行解答
lsof中附加不同参数产生的结果也不同,小心“踩坑”。
1、背景:
偶然发现数据库连不上,在数据库的err日志中,出现了“Too many open files”错误,都知道这个是mysqld进程触发了句柄限制,导致无法建立新连接。
度娘上面找到了统计句柄数的命令
lsof -n|awk '{print $2}'|sort|uniq -c|sort -nr| head -n 10
发现输出的结果远超了ulimit -n的结果。但是报错现象才持续不长时间,正常情况下不可能产生这么多句柄。
为了研究这个问题的根因,在自己的服务器上面模拟了以下测试。
服务器配置4C8G,MySQL 8.0.22,lsof版本为4.87(为什么特别介绍lsof版本,后续会提到,很重要)
2、测试过程:
1、在服务器上面安装好MySQL,设置下面的参数,重启数据库服务
max_connections=150
open_files_limit=1000
此时,数据库进程的open_files_limit为2160
mysql> show variables like '%open%';
+----------------------------+-------+
| Variable_name | Value |
+----------------------------+-------+
| have_openssl | YES |
| innodb_open_files | 1000 |
| mysqlx_port_open_timeout | 0 |
| open_files_limit | 2160 |
| table_open_cache | 1000 |
| table_open_cache_instances | 16 |
+----------------------------+-------+
6 rows in set (0.01 sec)
其计算公式为table_open_cache*2+max_connections+10 具体见下面的官网介绍
2、此时数据库刚刚启动,查看进程占用的句柄数
[root@greatdb mysql]# ps -ef| grep mysql
root 6239 8644 0 16:25 pts/5 00:00:00 mysql -uroot
root 10134 8260 0 16:42 pts/1 00:00:00 mysql -uroot
root 10177 1 0 16:47 ? 00:00:00 /bin/sh /usr/local/mysql/bin/mysqld_safe --defaults-file=/data/mysql/my.cnf
mysql 11604 10177 8 16:47 ? 00:00:02 /usr/local/mysql/bin/mysqld --defaults-file=/data/mysql/my.cnf --basedir=/usr/local/mysql --datadir=/data/mysql/data --plugin-dir=/usr/local/mysql/lib/plugin --user=mysql --log-error=/data/mysql/logs/mysqld-error.log --ope
n-files-limit=1000 --pid-file=/data/mysql/mysqld.pid --socket=/data/mysql/mysql.sock --port=3306root 11696 8572 0 16:47 pts/2 00:00:00 grep --color=auto mysql
[root@greatdb mysql]#
[root@greatdb mysql]#
[root@greatdb mysql]# lsof -n|awk '{print $2}'|sort|uniq -c|sort -nr| head -n 10
5727 11604
1575 1384
525 1550
455 879
371 561
135 1101
130 1001
120 16780
114 1304
88 16894
[root@greatdb mysql]#
可以看到刚刚启动的数据库,用上面的命令统计出来的句柄数5727就已经超过了设置的值2160了,但是数据库仍然可以正常使用和连接。
2、此时进入数据库,修改最大连接限制,用于模拟真实超过句柄的情况
set global max_connections=10000
3、在数据库中创建三个分区表,用于快速占用文件句柄数
create database test;
create table test.tb1(id int, c varchar(10)) partition by hash(id) partitions 1024;
create table test.tb2(id int, c varchar(10)) partition by hash(id) partitions 1024;
create table test.tb3(id int, c varchar(10)) partition by hash(id) partitions 1024;
4、此时再次使用上面的命令查询句柄数
[root@greatdb mysql]# lsof -n|awk '{print $2}'|sort|uniq -c|sort -nr| head -n 10
73485 11604
1575 1384
525 1550
455 879
371 561
135 1101
130 1001
120 16780
114 1304
88 16894
[root@greatdb mysql]#
5、可以看到mysql的进程“占用”句柄数已经达到73485,远远超过了实际允许的值了,开始怀疑这个统计值不对。
6、使用另外的命令 ** lsof -p 11604 |wc -l; ls /proc/11604/fd |wc -l** 来统计句柄和打开文件,发现比较正常,在合理范围内
[root@greatdb mysql]# lsof -p 11604 |wc -l; ls /proc/11604/fd |wc -l
1066
1021
[root@greatdb mysql]#
7、最终对比lsof -n | head 和lsof -p 11604 |head 发现了差异,lsof -n 的结果多了一列TID,观察后发现是线程编号,其值和performance_schema.threads中的thread_id能够对应上
[root@greatdb mysql]# lsof -p 11604 | head
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
mysqld 11604 mysql cwd DIR 253,1 4096 1310723 /data/mysql/data
mysqld 11604 mysql rtd DIR 253,1 4096 2 /
mysqld 11604 mysql txt REG 253,1 441771255 927033 /usr/local/mysql/bin/mysqld
mysqld 11604 mysql DEL REG 0,11 6526074 /[aio]
mysqld 11604 mysql DEL REG 0,11 6526073 /[aio]
mysqld 11604 mysql DEL REG 0,11 6526072 /[aio]
mysqld 11604 mysql DEL REG 0,11 6526071 /[aio]
mysqld 11604 mysql DEL REG 0,11 6526070 /[aio]
mysqld 11604 mysql DEL REG 0,11 6526069 /[aio]
[root@greatdb mysql]#
[root@greatdb mysql]#
[root@greatdb mysql]# lsof -n | head
COMMAND PID TID USER FD TYPE DEVICE SIZE/OFF NODE NAME
systemd 1 root cwd DIR 253,1 4096 2 /
systemd 1 root rtd DIR 253,1 4096 2 /
systemd 1 root txt REG 253,1 1632744 136135 /usr/lib/systemd/systemd
systemd 1 root mem REG 253,1 20064 132877 /usr/lib64/libuuid.so.1.3.0
systemd 1 root mem REG 253,1 265576 134383 /usr/lib64/libblkid.so.1.1.0
systemd 1 root mem REG 253,1 90176 132861 /usr/lib64/libz.so.1.2.7
systemd 1 root mem REG 253,1 157424 132876 /usr/lib64/liblzma.so.5.2.2
systemd 1 root mem REG 253,1 23968 133092 /usr/lib64/libcap-ng.so.0.0.0
systemd 1 root mem REG 253,1 19896 133076 /usr/lib64/libattr.so.1.1.0
8、经过多方咨询及资料查阅,了解到在lsof 4.82版本后,默认会统计出每个线程的句柄,即默认加上了-K参数,这样实现后,以前的命令 lsof -n|awk '{print $2}'|sort|uniq -c|sort -nr| head -n 10 统计出来的数据就约等于实际句柄数 * 线程数,也就是我们前面看到的结果,统计数据数字很大。
9、新lsof版本统计句柄正确的语法是 lsof -n -Ki|awk '{print $2}'|sort|uniq -c|sort -nr| head -n 10,统计出来后数据正常
[root@greatdb mysql]# lsof -Ki -n| awk '{print $2}' | sort | uniq -c | sort -nr | head
1065 11604
130 1001
91 879
84 8643
84 8641
84 8622
84 8603
84 8570
84 8258
84 8156
10、使用循环的方式,批量创建数据库会话连接,发现句柄到设置极限后,还会超45个句柄数,在此之后手动创建连接,会一直等待,mysql-err日志中出现错误“Too many open files”
for x in {1..1139}; do nohup mysql -uroot -e 'select sleep(240)' & done
11、在无法建立新连接的情况下,查询进程占用句柄数
[root@greatdb mysql]# lsof -p 11604 |wc -l
2205
12、至此找到正确统计进程句柄的方法,计算MySQL句柄上限计算方式,并且准确复现异常场景。
3、总结:
-
lsof 统计句柄数据,与版本有很大关系,如果是4.82之后的版本,统计进程句柄数,需要加上参数-Ki
-
MySQL启动时占用句柄数84,当table_open_cache设置为1000时,除开连接句柄,最多占用句柄1065个,主要包含共享库so、ibd文件、日志文件、临时文件等,每个链接再单独占用一个句柄
-
MySQL进程的最大句柄数,是参数open_files_limit + 45,这个是测试出来的,并没有找到具体代码出处
-
MySQL的句柄限制,是由参数max_connections、table_open_cache共同影响的,并且不受操作系统限制(测试了操作系统ulimit -n 1024的情况下,MySQL 的open_files_limit依然可以为2160)
-
文件句柄在线程间是共享的,因此打开一个ibd文件,不论有多少session访问,都只会占用一个句柄
参考文章
https://github.com/rapidoid/rapidoid/issues/105
https://github.com/draios/sysdig/issues/300
https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html
Enjoy GreatSQL 😃
文章推荐:
技术分享 | MGR最佳实践(MGR Best Practice)
https://mp.weixin.qq.com/s/66u5K7a9u8GcE2KPn4kCaA
技术分享 | 万里数据库MGR Bug修复之路
https://mp.weixin.qq.com/s/IavpeP93haOKVBt7eO8luQ
Macos系统编译percona及部分函数在Macos系统上运算差异
https://mp.weixin.qq.com/s/jAbwicbRc1nQ0f2cIa_2nQ
技术分享 | 利用systemd管理MySQL单机多实例
https://mp.weixin.qq.com/s/iJjXwd0z1a6isUJtuAAHtQ
产品 | GreatSQL,打造更好的MGR生态
https://mp.weixin.qq.com/s/ByAjPOwHIwEPFtwC5jA28Q
产品 | GreatSQL MGR优化参考
https://mp.weixin.qq.com/s/5mL_ERRIjpdOuONian8_Ow
关于 GreatSQL
GreatSQL是由万里数据库维护的MySQL分支,专注于提升MGR可靠性及性能,支持InnoDB并行查询特性,是适用于金融级应用的MySQL分支版本。
Gitee:
https://gitee.com/GreatSQL/GreatSQL
GitHub:
https://github.com/GreatSQL/GreatSQL
微信&QQ群:
可扫码添加GreatSQL社区助手微信好友,发送验证信息“加群”加入GreatSQL/MGR交流微信群,亦可直接扫码加入GreatSQL/MGR交流QQ群。
本文由博客一文多发平台 OpenWrite 发布!