文件句柄使用率超过阈值或连接数达到最大导致业务报错

【问题描述】

1、集群FI界面显示以下告警：文件句柄使用率超过阈值、TCP临时端口使用率超过阈值等；

2、业务无法正常执行，连接DataNode5以外节点cn_5001执行作业报dn_6001_6002达到最大连接数；

3、连接DataNode5上cn_5005执行作业报临时资源不可用。

【分析过程】

1、TCP临时端口使用率超过阈值

GaussDB A支持随机端口复用，临时端口使用超过65535不会影响业务，因此此告警不会导致问题。

 

2、文件句柄使用率超过阈值

1）查看DataNode5机器的os系统日志，搜kernel关键字，如下：

localhost:~ # grep kernel /var/log/messages
Jul 12 16:05:01 DataNode5 kernel: VFS: file-max limit 640000 reached
Jul 12 16:05:12 DataNode5 kernel: VFS: file-max limit 640000 reached
Jul 12 16:05:12 DataNode5 kernel: VFS: file-max limit 640000 reached
Jul 12 16:05:12 DataNode5 kernel: VFS: file-max limit 640000 reached
Jul 12 16:05:13 DataNode5 kernel: VFS: file-max limit 640000 reached
Jul 12 16:05:13 DataNode5 kernel: VFS: file-max limit 640000 reached
Jul 12 16:05:13 DataNode5 kernel: VFS: file-max limit 640000 reached
Jul 12 16:05:14 DataNode5 kernel: VFS: file-max limit 640000 reached
Jul 12 16:05:14 DataNode5 kernel: VFS: file-max limit 640000 reached
Jul 13 09:51:46 DataNode5 kernel: VFS: file-max limit 640000 reached
omm@localhost:~ #

2）查操作系统配置的最大文件句柄数

localhost:~ # sysctl -p|grep file-max
fs.file-max = 640000

3）统计进程使用句柄数情况

localhost:~ # lsof -n|awk '{print $2}'|sort|uniq -c|sort -nr|more

由于文件句柄较多，统计较慢

4）统计gaussdb各进程使用的文件句柄

# 查找gaussdb进程
ps ux
# 查看某个进程使用的文件句柄数
ls /proc/pid/fd | wc -l

# 结果排查，发现cn（此cn为cn_5005）进程所占的文件句柄数最多，如下图，达到57万，略有异常，继续分析。

5） 排查cn_5005日志，重点关注7月12号下午16:05的日志信息，如下，“remaining connection slots are reserved for non-replication system admin connections”和“dn_6037_6038: sorry, too many clients already, active/non-active: 5/2995.”均表明当前系统连接数已经达到设置的最大max_connections，不能在建连。

继续确认进程启动时间并与客户确认，上一次重启时间为19年12月，8.0之前的版本，客户持续运行7个月以上，连接数可能会一直增大，这时需要用户手动执行clean connection to all for database dbtest;去清理空闲连接，否则继续建连会出现上述报错提示，且也会由于连接数太多占用内存导致执行时报临时资源不可用。

疑问：

客户集群共部署4个CN节点，且采用LVS负载均衡，正常情况下，LVS会将作业均衡的分发给每个CN节点，但目前只有datanode5节点报文件句柄数达到最大？？

6）继续排查其它机器所占用的文件句柄数，如下图只有12万+，怀疑可能是LVS异常。

7）与客户对齐发现，客户在使用LVS过程中，跑大量insert语句，刚开始运行时，观察每个cn上都会运行insert语句，运行到10小时之后（20小时才能跑完），LVS只往某两个cn上下发作业，这会导致上述cn_5005连接数远远大于其他节点。

【问题根因】

连接数太多导致系统业务报错

【闭环方案】

客户反馈近期会升级到8.0版本，8.0版本已加入自动清理空闲连接操作，不会再出现此类报错。

【恢复方案】

法一：清理空闲连接：clean connection to all for database dbtest;

法二：集群重启后恢复