GreatSQL temp文件占用时长分析

GreatSQL DBA在日常工作中可能会遇到这种情况，存在一个 InnoDB 引擎下的 temp_x.ibt 文件很大，但是却无法确定这个文件是什么时间由哪个连接建立的，难以支撑后续定位问题，今天这篇文章彻底讲明白这个问题。

现象：发现一个实例下面（4406端口对外提供服务的实例）temp文件很大，如下所示：

-rw-r----- 1 greatsql greatsql 81920 Sep 26 23:56 temp_1.ibt -rw-r----- 1 greatsql greatsql 81920 Sep 30 16:43 temp_10.ibt -rw-r----- 1 greatsql greatsql 81920 Sep 26 23:56 temp_2.ibt -rw-r----- 1 greatsql greatsql 81920 Sep 26 23:56 temp_3.ibt -rw-r----- 1 greatsql greatsql 81920 Sep 26 23:56 temp_4.ibt -rw-r----- 1 greatsql greatsql 18392023040 Oct 9 15:56 temp_5.ibt -rw-r----- 1 greatsql greatsql 18417188864 Oct 11 14:51 temp_6.ibt -rw-r----- 1 greatsql greatsql 18417188864 Oct 11 14:51 temp_7.ibt -rw-r----- 1 greatsql greatsql 18392023040 Oct 9 15:54 temp_8.ibt -rw-r----- 1 greatsql greatsql 81920 Sep 30 16:43 temp_9.ibt $ cd /data/greatsql/dbdata/datanode4406/data/#innodb_temp $ du -sm temp_6.ibt 17565 temp_6.ibt 

单个文件大小达到17G，而且还在持续增加。

那么，这个文件是由那个连接占用的呢？

$ ps -ef|grep greatsql|grep 4406 greatsql 35049 33132 88 Sep26 ? 15-18:21:22 /data/greatsql/svr/greatsql/bin/greatsqld --defaults-file=/greatsql/conf/datanode4406.cnf --basedir=/greatsql/svr/greatsql --datadir=/greatsql/dbdata/datanode4406/data --plugin-dir=/greatsql/svr/greatsql/lib/plugin --log-error=/greatsql/logs/error4406.log --pid-file=/greatsql/dbdata/datanode4406/data/greatsql.pid --socket=/greatsql/dbdata/datanode4406/data/greatsql.sock --port=4406 

通过上述命令可以得到GreatSQL的进程ID。

GreatSQL数据库的进程为35049接下来通过命令查看这个进程打开的这个连接的文件名，lsof -p pid|grep port或者lsof 目录名称，可以得到这个进程在在这个端口上的连接的文件编号：

$ lsof /data/greatsql/dbdata/datanode4406/data/#innodb_temp/temp_6.ibt COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME greatsqld 35049 greatsql 282uW REG 8,17 18417188864 16642999840 /data/greatsql/dbdata/datanode4406/data/#innodb_temp/temp_6.ibt 

/proc/[pid]/fd 是一个目录，包含进程打开文件的情况，大家注意到 282uW 这个值，其中数字部分代表fdid，这个里面282就是代表fdid，然后执行下面的命令：

$ ll /proc/35049/fd/282 lrwx------ 1 greatsql greatsql 64 Sep 26 23:57 /proc/35049/fd/282 -> /data/greatsql/dbdata/datanode4406/data/#innodb_temp/temp_6.ibt 

这样就得到连接建立这个文件的时间了，通过这个方法判断是否为长期不释放的连接，然后通过数据库的information_schema.innodb_session_temp_tablespaces，找到连接会话ID，它与information_schema.processlist的ID是一一对应关系，从而进行下一步研判和深度分析处理，异常的长连接可以kill处理，如下图 KILL 907即可。

greatsql> SELECT * FROM information_schema.innodb_session_temp_tablespaces ; +---------+------------+----------------------------+-------------+----------+-----------+ | ID | SPACE | PATH | SIZE | STATE | PURPOSE | +---------+------------+----------------------------+-------------+----------+-----------+ | 29356 | 4243767288 | ./#innodb_temp/temp_8.ibt | 18392023040 | ACTIVE | INTRINSIC | | 473 | 4243767285 | ./#innodb_temp/temp_5.ibt | 18392023040 | ACTIVE | INTRINSIC | | 907 | 4243767286 | ./#innodb_temp/temp_6.ibt | 18417188864 | ACTIVE | INTRINSIC | | 501 | 4243767287 | ./#innodb_temp/temp_7.ibt | 18417188864 | ACTIVE | INTRINSIC | | 1798928 | 4243767284 | ./#innodb_temp/temp_4.ibt | 245760 | ACTIVE | INTRINSIC | | 0 | 4243767281 | ./#innodb_temp/temp_1.ibt | 81920 | INACTIVE | NONE | | 0 | 4243767282 | ./#innodb_temp/temp_2.ibt | 81920 | INACTIVE | NONE | | 0 | 4243767290 | ./#innodb_temp/temp_10.ibt | 81920 | INACTIVE | NONE | | 0 | 4243767289 | ./#innodb_temp/temp_9.ibt | 81920 | INACTIVE | NONE | | 0 | 4243767283 | ./#innodb_temp/temp_3.ibt | 81920 | INACTIVE | NONE | +---------+------------+----------------------------+-------------+----------+-----------+ 10 rows in set (0.00 sec) greatsql> KILL 907 Query OK, 0 rows affected (0.00 sec) 

感谢大家观看，不足之处还请指正。

Enjoy GreatSQL :)

关于 GreatSQL

GreatSQL是适用于金融级应用的国内自主开源数据库，具备高性能、高可靠、高易用性、高安全等多个核心特性，可以作为MySQL或Percona Server的可选替换，用于线上生产环境，且完全免费并兼容MySQL或Percona Server。

相关链接： GreatSQL社区 Gitee GitHub Bilibili

GreatSQL社区：

社区有奖建议反馈： https://greatsql.cn/thread-54-1-1.html

社区博客有奖征稿详情： https://greatsql.cn/thread-100-1-1.html

（对文章有疑问或者有独到见解都可以去社区官网提出或分享哦~）

技术交流群：

微信&QQ群：

QQ群：533341697

微信群：添加GreatSQL社区助手（微信号：wanlidbc ）好友，待社区助手拉您进群。