从源码角度谈谈open_files_limit的生成逻辑及"Too many open files"的解决思路

本文主要是介绍从源码角度谈谈open_files_limit的生成逻辑及"Too many open files"的解决思路，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

“Too many open files”是一个比较常见的错误，不仅仅是在 MySQL 中。只要是在 Linux 中启动的进程，都有可能遇到这个错误。

究其原因，是进程打开的文件描述符数超过了自身的限制。

这个限制，是进程级别的，在 MySQL 中，与 open_files_limit 的设置有关。

但是 open_files_limit 并不是所设即所得，配置的和实际生效的并不完全一样。

一、测试Demo

配置文件中的配置。

open_files_limit = 65536
table_open_cache = 1000
max_connections = 2000

切换到 mysql 用户下，启动实例，看看这三个参数，外加 table_definition_cache 的实际有效值。

[root@node1 ~]# su - mysql

[mysql@node1 ~]$ /usr/local/mysql5.7.34/bin/mysqld --defaults-file=/etc/my.cnf &

mysql> select @@open_files_limit,@@table_open_cache,@@max_connections,@@table_definition_cache;
+--------------------+--------------------+-------------------+--------------------------+
| @@open_files_limit | @@table_open_cache | @@max_connections | @@table_definition_cache |
+--------------------+--------------------+-------------------+--------------------------+
|               2048 |                400 |              1238 |                      600 |
+--------------------+--------------------+-------------------+--------------------------+
1 row in set (0.01 sec)

实际值和配置值，竟然没有一个相同，是不是很意外？

二、源码分析

下面，结合源码看看这三个参数的生成逻辑。

# vim mysql-5.7.34/sql/mysqld.cc

#ifdef _WIN32
int win_main(int argc, char **argv)
#else
int mysqld_main(int argc, char **argv)
#endif
{
  ...
  sys_var_init();
  ulong requested_open_files;
  adjust_related_options(&requested_open_files);
  ...
}

其中：

sys_var_init()：初始化系统参数（System Variables）。
adjust_related_options()：在初始化的基础上，调整相关参数的配置。

下面看看 adjust_related_options 的处理逻辑

void adjust_related_options(ulong *requested_open_files)
{
  /* In bootstrap, disable grant tables (we are about to create them) */
  if (opt_bootstrap)
    opt_noacl= 1;

  /* The order is critical here, because of dependencies. */
  adjust_open_files_limit(requested_open_files);
  adjust_max_connections(*requested_open_files);
  adjust_table_cache_size(*requested_open_files);
  adjust_table_def_size();
}

其中，

adjust_open_files_limit：调整 open_files_limit，调整后的值会赋值给 requested_open_files。
adjust_max_connections：调整 max_connections，依赖于 requested_open_files，即调整后的 open_files_limit。
adjust_table_cache_size：调整 table_cache_size，依赖于调整后的 open_files_limit 和 max_connections。
adjust_table_def_size：调整 table_definition_cache，依赖于调整后的 table_cache_size。

这四个参数中，最为复杂的是 open_files_limit 的调整，它涉及到系统对进程能打开的最大文件描述符的限制。

不妨，先基于调整后的 open_files_limit，看看后面三个参数的调整逻辑。

2.1 max_connections

首先，看看 max_connections 的取值逻辑

void adjust_max_connections(ulong requested_open_files)
{
  ulong limit;

  limit= requested_open_files - 10 - TABLE_OPEN_CACHE_MIN * 2;

  if (limit < max_connections)
  {
    sql_print_warning("Changed limits: max_connections: %lu (requested %lu)",
                      limit, max_connections);

    // This can be done unprotected since it is only called on startup.
    max_connections= limit;
  }
}

其中，

requested_open_files：调整后的 open_files_limit。具体在本 Demo，是 2048。
TABLE_OPEN_CACHE_MIN：常量，代表 table_cache_size 可允许的最小值。
```
#define TABLE_OPEN_CACHE_MIN    400
```
max_connections：max_connections 的初始值。取配置文件中的配置，2000。如果配置文件中没有设置，则默认为 151。

基于代码中的计算逻辑，limit = 2048 - 10 - 400 * 2 = 1238。

1238 小于 2000，所以 max_connections 最后取值为 1238，与 Demo 开头的查询结果一致。

2.2 table_cache_size

接下来，看看 table_cache_size 的取值逻辑

void adjust_table_cache_size(ulong requested_open_files)
{
  ulong limit;

  limit= max<ulong>((requested_open_files - 10 - max_connections) / 2,
                    TABLE_OPEN_CACHE_MIN);

  if (limit < table_cache_size)
  {
    sql_print_warning("Changed limits: table_open_cache: %lu (requested %lu)",
                      limit, table_cache_size);

    table_cache_size= limit;
  }

  table_cache_size_per_instance= table_cache_size / table_cache_instances;
}

其中，

max_connections：max_connections 调整后的的值，即 1238。
table_cache_instances：table_open_cache_instances。
table_cache_size：table_cache_size 的初始值。在这个 Demo 中，是 1000。

基于代码中的计算逻辑，limit = max( ( 2048 - 10 - 1238 ) / 2，400 ) = 400。

400 小于 1000，所以，table_cache_size 最后取值为 400。

2.3 table_definition_cache

接下来，看看 table_definition_cache 的取值逻辑

void adjust_table_def_size()
{
  ulong default_value;
  sys_var *var;

  default_value= min<ulong> (400 + table_cache_size / 2, 2000);
  var= intern_find_sys_var(STRING_WITH_LEN("table_definition_cache"));
  assert(var != NULL);
  var->update_default(default_value);

  if (! table_definition_cache_specified)
    table_def_size= default_value;
}

同样，table_cache_size 也是调整后的值，即 400。

default_value = min( 400 + 400 / 2，2000) = 600。

顾名思义，default_value 是默认值。如果没有显式设置 table_definition_cache，则取默认值。

2.4 open_files_limit

最后看看 open_files_limit 的取值逻辑

void adjust_open_files_limit(ulong *requested_open_files)
{
  ulong limit_1;
  ulong limit_2;
  ulong limit_3;
  ulong request_open_files;
  ulong effective_open_files;

  /* MyISAM requires two file handles per table. */
  limit_1= 10 + max_connections + table_cache_size * 2;

  /*
    We are trying to allocate no less than max_connections*5 file
    handles (i.e. we are trying to set the limit so that they will
    be available).
  */
  limit_2= max_connections * 5;

  /* Try to allocate no less than 5000 by default. */
  limit_3= open_files_limit ? open_files_limit : 5000;

  request_open_files= max<ulong>(max<ulong>(limit_1, limit_2), limit_3);

  /* Notice: my_set_max_open_files() may return more than requested. */
  effective_open_files= my_set_max_open_files(request_open_files);

  if (effective_open_files < request_open_files)
  {
    if (open_files_limit == 0)
    {
      sql_print_warning("Changed limits: max_open_files: %lu (requested %lu)",
                        effective_open_files, request_open_files);
    }
    else
    {
      sql_print_warning("Could not increase number of max_open_files to "
                        "more than %lu (request: %lu)",
                        effective_open_files, request_open_files);
    }
  }

  open_files_limit= effective_open_files;
  if (requested_open_files)
    *requested_open_files= min<ulong>(effective_open_files, request_open_files);
}

因为是最先调整的参数，所以，这里的 max_connections，table_cache_size，open_files_limit 都是初始值。

基于代码中的计算逻辑，

limit_1 = 10 + max_connections + table_cache_size _ 2 = 10 + 2000 + 1000 _ 2 = 4100
limit_2 = max_connections _ 5 = 2000 _ 5 = 10000
limit_3 = open_files_limit ? open_files_limit : 5000 = 65536

request_open_files = max(max(limit_1, limit_2), limit_3) = 65536，可理解为需要打开的文件数。

接下来，调用 my_set_max_open_files 函数获取 effective_open_files，后者是实际能打开的最大文件数。

看看 my_set_max_open_files 的处理逻辑。

uint my_set_max_open_files(uint files)
{
  struct st_my_file_info *tmp;
  DBUG_ENTER("my_set_max_open_files");
  DBUG_PRINT("enter",("files: %u  my_file_limit: %u", files, my_file_limit));

  files+= MY_FILE_MIN;
  files= set_max_open_files(MY_MIN(files, OS_FILE_LIMIT));
  if (files <= MY_NFILE)
    DBUG_RETURN(files);

  if (!(tmp= (struct st_my_file_info*) my_malloc(key_memory_my_file_info,
                                                 sizeof(*tmp) * files,
                                                 MYF(MY_WME))))
    DBUG_RETURN(MY_NFILE);

  /* Copy any initialized files */
  memcpy((char*) tmp, (char*) my_file_info,
         sizeof(*tmp) * MY_MIN(my_file_limit, files));
  memset((tmp + my_file_limit), 0,
        MY_MAX((int) (files - my_file_limit), 0) * sizeof(*tmp));
  my_free_open_file_info();                     /* Free if already allocated */
  my_file_info= tmp;
  my_file_limit= files;
  DBUG_PRINT("exit",("files: %u", files));
  DBUG_RETURN(files);
}

三、进程RLIMIT_NOFILE的决定因素

同样的设置，如果 mysqld 是在 root 用户下启动呢？

[root@node1 ~]# /usr/local/mysql5.7.34/bin/mysqld --defaults-file=/etc/my.cnf &

mysql> select @@open_files_limit,@@table_open_cache,@@max_connections,@@table_definition_cache;
+--------------------+--------------------+-------------------+--------------------------+
| @@open_files_limit | @@table_open_cache | @@max_connections | @@table_definition_cache |
+--------------------+--------------------+-------------------+--------------------------+
|             100000 |               1000 |              2000 |                      900 |
+--------------------+--------------------+-------------------+--------------------------+
1 row in set (0.00 sec)

竟然不是 65536，而是 100000。

3.1 启动用户

这个实际上与启动用户有关。用户决定了通过它启动的进程的资源上限，包括文件描述符数。

这里的上限，是在/etc/security/limits.conf 中定义的。如本 Demo 中的配置，

root     soft        nofile       100000
root     hard        nofile       100000
mysql    soft        nofile       2048
mysql    hard        nofile       4096

注意，这里虽然配置的是用户，但实际上限制的是通过用户启动的进程。

一般建议显式设置，如果不设置的话，则默认是 1024。1024，对于大多数应用来说，还是太小了。

用户可自由调整软限制和硬限制的大小，但需遵循以下规则：

软限制必须小于等于硬限制。
硬限制可以调小，但不能低于软限制。

除此之外，

如果是普通用户，对于硬限制的调整是不可逆的，即一旦调小，就不能再调大。
如果是 root 用户，则没有限制。但不能无限调大，最大值受到/proc/sys/fs/nr_open 的限制。后者决定了单个进程可打开的最大文件描述符数。

3.2 启动脚本

除了启动用户，启动脚本也能限制进程的资源使用。

看下面这个 Demo，同样是在 root 用户下，只不过这次是通过 mysqld_safe 启动。

同样是在 root 用户下，如果是通过 mysqld_safe 启动呢？

[root@node1 ~]# /usr/local/mysql5.7.34/bin/mysqld_safe --defaults-file=/etc/my.cnf &

mysql> select @@open_files_limit,@@table_open_cache,@@max_connections,@@table_definition_cache;
+--------------------+--------------------+-------------------+--------------------------+
| @@open_files_limit | @@table_open_cache | @@max_connections | @@table_definition_cache |
+--------------------+--------------------+-------------------+--------------------------+
|              65536 |               1000 |              2000 |                      900 |
+--------------------+--------------------+-------------------+--------------------------+
1 row in set (0.00 sec)

竟然是 65536。

这背后，其实是 mysqld_safe 在“捣鬼”。

USER_OPTION=""
if test -w / -o "$USER" = "root"
then
  if test "$user" != "root" -o $SET_USER = 1
  then
    USER_OPTION="--user=$user"
  fi
  if test -n "$open_files"
  then
    ulimit -n $open_files
  fi
fi

parse_arguments() {
...
      --open-files-limit=*) open_files="$val" ;;
      --open_files_limit=*) open_files="$val" ;;
...
}

具体来说，如果配置文件或命令行中显式设置了 open_files_limit，则 mysqld_safe 在启动的过程中会通过“ulimit -n $open_files”调整进程的最大文件描述符数。

除了启动脚本，在 CentOS 7 中，如果是通过 systemd 管理进程，还可通过 LimitNOFILE 在进程级别设置文件描述符数的上限。

LimitNOFILE=102400

3.3 小结

进程能打开的最大文件描述符数由启动用户决定。除此之外，启动脚本（包括systemd），能在进程级别设置文件描述符数的上限。

四、Too many open files

文件描述符不够，在 MySQL 中的影响主要有：

连接创建失败。相关的报错如下：

[ERROR] Error in accept: Too many open files in system

查询失败。相关的报错如下：

[ERROR] /usr/local/mysql5.7.34/bin/mysqld: Can't open file: './sbtest/t4.frm' (errno: 24 - Too many open files)

4.1 常见原因

出现“Too many open files”，常见的原因有两个：

系统可打开的文件描述符数达到了上限。这里的上限，指的是系统内核的上限，由/proc/sys/fs/file-max 决定。
进程可打开的文件描述符数达到了上限。

之所以要区分这两种场景，是因为两者的解决方法不一样。

如何判断是哪个原因导致的呢？

查看系统文件描述符的使用情况。
```
cat /proc/sys/fs/file-nr
2752    0       65536
```
输出有三列，如果第一列大于等于第三列，则意味着系统可打开的文件描述符数达到了上限。

第一列：已分配的文件描述符数。
第二列：可用的文件描述符数。
第三列：内核能分配的最大文件描述符数，由/proc/sys/fs/file-max 决定。

/var/log/messages。

如果系统可打开的文件描述符数达到了上限，/var/log/messages 还会出现以下报错。
```
kernel: [8314414.667267] VFS: file-max limit 65536 reached
```

4.2 解决方法

确定了原因，下面看看解决方法。

4.2.1 针对原因一，系统可使用的文件描述符数达到了上限。

看看哪些进程打开的文件最多。
```
lsof -n|awk '{print $2}'|sort|uniq -c|sort -nr
```
输出有两列，第一列是打开的文件的个数，第二列是进程号。
通过进程号定位具体的进程。
```
ps -ef | grep ${PID}
```
分析打开文件最多的进程，或 KILL，或重启，或优化。
如果短期内不能优化解决的，可先临时调大 file-max 的值。
```
echo 100000 > /proc/sys/fs/file-max
```
这里修改的是内存值，机器重启就会失效。如果要永久生效，还需修改/etc/sysctl.conf。
```
# vim /etc/sysctl.conf
fs.file-max=100000

# sysctl -p
```

4.2.2 针对原因二，进程可使用的文件描述符数达到了上限。

查看进程的最大文件描述符数。

cat /proc/${PID}/limits | grep "Max open files"

查看进程当前打开的文件描述符数。
```
lsof -p ${PID} | wc -l
```
调整进程的最大文件描述符数。

从 CentOS 6 开始，支持在线调整进程的最大文件描述符数，无需重启进程。
```
#CentOS 6
echo -n "Max open files=102400:102400" > /proc/${PID}/limits

#CentOS 7
prlimit --pid ${PID} --nofile=102400:102400
```
注意，CentOS 6 的调整方式在 CentOS 7 中不适用，同样，CentOS 6 中也不支持 prlimit 命令。

这就意味着，后续MySQL出现“Too many open files”错误，再也不用重启进程了。

如果系统不支持在线调整进程的最大文件描述符数。就只能修改配置，重启实例。具体步骤如下：

首先查看进程的启动用户。
```
ps -ef | grep mysqld
```
获取 mysqld 父进程的 ID（PPID），对应输出的第三列。

基于 PPID 查看 mysqld 的父进程。
```
ps -ef | grep ${PPID}
```
第一列显示的用户就是启动用户。
修改启动用户可打开的最大文件描述符数。
```
vim /etc/security/limits.conf
```
修改 open_files_limit 的配置，重启实例。

无论是在线，还是通过/etc/security/limits.conf，调整进程的最大文件描述符数，在调整的时候，注意以下几点：

进程的最大文件描述符数不能超过/proc/sys/fs/nr_open 的大小。
如果修改了/proc/sys/fs/nr_open，需同步修改/proc/sys/fs/file-max，后者代表了内核能分配的最大文件描述符数。
为了保证配置在系统重启后依然有效，建议同步修改/etc/sysctl.conf。
```
# vim /etc/sysctl.conf
fs.nr_open=100000
fs.file-max=100000

# sysctl -p
```

五、查看进程当前打开的文件描述符数

在 MySQL 状态变量中，没有能直观反映文件描述符的指标。

看下面这个 Demo。

open_files_limit 等于 1024，当文件描述符不足，出现“Too many open files”错误时，mysql 状态变量及 lsof 的统计结果如下：

mysql> show global status where variable_name like 'open%' or variable_name='innodb_num_open_files';
+--------------------------+-------+
| Variable_name            | Value |
+--------------------------+-------+
| Innodb_num_open_files    | 431   |
| Open_files               | 2     |
| Open_streams             | 0     |
| Open_table_definitions   | 615   |
| Open_tables              | 578   |
| Opened_files             | 1303  |
| Opened_table_definitions | 1260  |
| Opened_tables            | 1928  |
+--------------------------+-------+
8 rows in set (0.00 sec)

mysql> select @@open_files_limit,@@innodb_open_files;
+--------------------+---------------------+
| @@open_files_limit | @@innodb_open_files |
+--------------------+---------------------+
|               1024 |                 431 |
+--------------------+---------------------+
1 row in set (0.01 sec)

其中，

Innodb_num_open_files：InnoDB 当前打开的文件数。InnoDB 同时能打开的最大文件数由 innodb_open_files 参数决定，后者默认为-1，基于 table_cache_size 自动调整。

innodb_open_files 并不是一个硬限制。如果 InnoDB 打开的文件数达到了 innodb_open_files 的限制，则会通过 LRU 算法关闭其它文件。

if (innobase_open_files < 11) {
        innobase_open_files = 300;
        if (srv_file_per_table && table_cache_size > 300) {
                innobase_open_files = table_cache_size;
        }
}

if (innobase_open_files > (long) open_files_limit) {
        ib::warn() << "innodb_open_files should not be greater"
               " than the open_files_limit.\n";
        if (innobase_open_files > (long) table_cache_size) {
                innobase_open_files = table_cache_size;
        }
}

Open_files：当前打开的文件数。
Opened_files：打开过的文件数。

从输出结果来看，这三个变量的值与 open_files_limit（1024）相去甚远，不如 lsof 的准确。

[root@node1 ~]# lsof -p 9020 | wc -l
1054

其中，9020 是进程的 PID。

lsof 同样适用于其它进程的统计。

六、总结

open_files_limit 会取以下三个值中的最大值。

limit_1 = 10 + max_connections + table_cache_size * 2。
limit_2 = max_connections * 5。
limit_3 = open_files_limit ? open_files_limit : 5000。

如果进程的最大文件描述符数超过 open_files_limit，则实际生效的的是进程的最大文件描述符数。
如果进程的最大文件描述符数小于 open_files_limit，需区分启动用户。

3.1 如果启动用户是 root，则实际生效的是 open_files_limit。

3.2 如果启动用户是普通用户。

open_files_limit 小于等于硬限制，则实际生效的是 open_files_limit。
open_files_limit 大于硬限制，则实际生效的是进程的最大文件描述符数。

如果进程是通过 mysqld_safe 启动的，则 mysqld_safe 会基于 open_files_limit 调整进程的最大文件描述符数。
在源码里，其实还区分了一个场景，即最大文件描述符数为 unlimited。但实际上，在 RHEL 及其衍生版本中，不允许将 nofile 设置为 unlimited。
```
# ulimit -n unlimited
-bash: ulimit: open files: cannot modify limit: Operation not permitted
```
虽然允许在/etc/security/limits.conf 文件中将 nofile 设置为 unlimited，但效果等同于 0，此时，相关用户不能创建新的进程，也不允许登录。
```
# su - mysql
su: cannot open session: Permission denied

# ssh mysql@192.168.244.10
Connection to 192.168.244.10 closed.
```
在调整进程的最大文件描述符数时，注意：单个进程的最大文件描述符数 <= fs.nr_open <= fs.file-max
从 CentOS 6 开始，可在线调整进程的最大文件描述符数，无需重启进程。

七、参考资料

https://man7.org/linux/man-pages/man2/getrlimit.2.html

https://www.ibm.com/docs/en/sdk-java-technology/7?topic=rja-system-resource-limits-ulimit-command

这篇关于从源码角度谈谈open_files_limit的生成逻辑及"Too many open files"的解决思路的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！

Java教程

从源码角度谈谈open_files_limit的生成逻辑及"Too many open files"的解决思路

一、测试Demo

二、源码分析

2.1 max_connections

2.2 table_cache_size

2.3 table_definition_cache

2.4 open_files_limit

三、进程RLIMIT_NOFILE的决定因素

3.1 启动用户

3.2 启动脚本

3.3 小结

四、Too many open files

4.1 常见原因

如何判断是哪个原因导致的呢？

4.2 解决方法

4.2.1 针对原因一，系统可使用的文件描述符数达到了上限。

4.2.2 针对原因二，进程可使用的文件描述符数达到了上限。

五、查看进程当前打开的文件描述符数

六、总结

七、参考资料

前端开发

后端开发

移动端开发

数据库

服务器运维

人工智能

区块链

游戏开发

网站运营

大数据/云计算

软件工程

软件/开发工具使用

资讯

从源码角度谈谈open_files_limit的生成逻辑及"Too many open files"的解决思路

​一、测试Demo

二、源码分析

2.1 max_connections

2.2 table_cache_size

2.3 table_definition_cache

2.4 open_files_limit

三、进程RLIMIT_NOFILE的决定因素

3.1 启动用户

3.2 启动脚本

3.3 小结

四、Too many open files

4.1 常见原因

如何判断是哪个原因导致的呢？

4.2 解决方法

4.2.1 针对原因一，系统可使用的文件描述符数达到了上限。

4.2.2 针对原因二，进程可使用的文件描述符数达到了上限。

五、查看进程当前打开的文件描述符数

六、总结

七、参考资料

前端开发

后端开发

移动端开发

数据库

服务器运维

人工智能

区块链

游戏开发

网站运营

大数据/云计算

软件工程

软件/开发工具使用

资讯

一、测试Demo