是否可以检查一个特定的查询在MySQL中打开了多少个文件？

Question

我在MySQL中有大量的开放文件限制。

我已经将open_files_limit设置为150000，但是MySQL仍然使用几乎80%的。

此外，我有低流量和最大并发连接在30左右，没有查询有超过4个连接。

Answer 1

服务器打开的文件在performance_schema中可见。

见表performance_schema.file_instances。

http://dev.mysql.com/doc/refman/5.5/en/file-instances-table.html

至于跟踪哪个查询打开哪个文件，由于服务器本身的缓存(表缓存、表定义缓存)，它不能这样工作。

Answer 2

MySQL不应该打开那么多文件，除非您为table_cache参数设置了一个可笑的大值(默认值为64，最大值为512 K)。

您可以通过发出FLUSH TABLES命令来减少打开文件的数量。

否则，可以通过对所有table_cache线程运行strace -c来粗略估计(在Linux中) MySQLd的适当值。你会得到这样的东西：

# strace -f -c -p $( pidof mysqld )
Process 13598 attached with 22 threads
[ ...pause while it gathers information... ]
^C
Process 13598 detached
...
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 58.82    0.040000          51       780           io_getevents
 29.41    0.020000         105       191        93 futex
 11.76    0.008000         103        78           select
  0.00    0.000000           0        72           stat
  0.00    0.000000           0        20           lstat
  0.00    0.000000           0        16           lseek
  0.00    0.000000           0        16           read
  0.00    0.000000           0         9         3 open
  0.00    0.000000           0         5           close
  0.00    0.000000           0         6           poll
...
------ ----------- ----------- --------- --------- ----------------

...and查看open()和close()调用的影响是否存在合理的差异；这些调用是table_cache影响的，并且影响到在任何给定点上打开文件的数量。

如果open()的影响可以忽略不计，那么一定会减少的影响。它主要是在缓慢的苔藓上需要的，而剩下的也不多了。

如果您在Windows上运行，则必须尝试使用ProcMon由SysInternals提供，或者类似的工具。

一旦table_cache达到了可管理的级别，现在打开太多文件的查询就会关闭并重新打开许多相同的文件。你可能会注意到对表演的影响，这很可能是可以忽略不计的。较小的表缓存可能会更快地获得结果，因为从现代的、快速的IOSS缓存中获取项可能比在非常大的缓存中搜索它更快。

如果您想优化您的服务器，您可能也想看看这篇文章。带走的是，随着缓存的发展，更大并不总是更好的(它也适用于索引)。

检查Linux上的特定查询

在Linux上，您可以使用strace (见上文)并验证打开了哪些文件以及如何打开：

$ sudo strace -f -p $( pidof mysqld ) 2>&1 | grep 'open("'

同时，从另一个终端运行一个查询，并且：

[pid  8894] open("./ecm/db.opt", O_RDONLY) = 39
[pid  8894] open("./ecm/prof2_people.frm", O_RDONLY) = 39
[pid  8894] open("./ecm/prof2_discip.frm", O_RDONLY) = 39
[pid  8894] open("./ecm/prof2_discip.ibd", O_RDONLY) = 19
[pid  8894] open("./ecm/prof2_discip.ibd", O_RDWR) = 19
[pid  8894] open("./ecm/prof2_people.ibd", O_RDONLY) = 20
[pid  8894] open("./ecm/prof2_people.ibd", O_RDWR) = 20
[pid  8894] open("/proc/sys/vm/overcommit_memory", O_RDONLY|O_CLOEXEC) = 39

...these是查询使用的文件(*确保在“冷启动”MySQL上运行查询以防止缓存)，我看到分配的最高文件句柄是39，因此在任何时候都没有超过40个打开的文件。

可以从/proc/$PID/fd或从MySQL中检查相同的文件：

select * from performance_schema.file_instances where open_count > 1;

但是MySQL的计数稍微短一些，它不考虑套接字描述符、日志文件和临时文件。

Answer 3

只有通过调整源代码并在该级别上添加日志记录，才能做到这一点。

ALternative:使用此场景运行测试：

为了实现这一点，您必须设置一个自动测试：

• 记录您的查询；
• 创建一个脚本，用一个普通的数据集预加载您的堆(否则您正在测试空内存)，对打开的表的数量进行快照；
• 运行每个查询并获取打开表的快照；(回顾一下)我认为您可以在不每次重新启动MySQL的情况下这样做，所以只需每次查询并记录结果。调试是一项乏味的工作:并非不可能，只是非常乏味。

就我个人而言，我的出发点会有所不同：

• 安装仙人掌和percona仙人掌插件
• 注册一个星期的正常工作量
• 然后查找高负载查询(慢速日志>0.1秒，通过脚本查找重复查询)。
• 另一个星期的监测
• 然后查找具有高重复次数的其他查询:这通常是效率低下的代码，在可以使用较少的查询的地方触发大量查询(比如检索键，然后每个键的所有值(一个接一个:程序员使用ORM时经常发生)。