故障案例 | lsof是怎么"影响"MySQL计算打开文件句柄数的
阅读原文时间:2023年07月10日阅读:5

欢迎来到 GreatSQL社区分享的MySQL技术文章,如有疑问或想学习的内容,可以在下方评论区留言,看到后会进行解答

lsof中附加不同参数产生的结果也不同,小心“踩坑”。

偶然发现数据库连不上,在数据库的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版本,后续会提到,很重要)

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句柄上限计算方式,并且准确复现异常场景。

  • 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 发布!