【此文抄自同事的郵件，當作筆記學習】

環(huán)境描述
Mysql 5.5.21
OS centos 5.8
zabbix agent 2.4.3

情況描述
現(xiàn)象數(shù)據(jù)庫處于運行狀態(tài)，但是無法創(chuàng)建新的連接，監(jiān)控報警數(shù)據(jù)庫無法連接，連接不上MySQL，一直處于等待狀態(tài)。

Mysql的error日志報錯：

[ERROR] /usr/sbin/mysqld: Can't find file: './wukong_customs/wukong_task_info.frm' (errno: 23)
[ERROR] Error in accept: Too many open files in system

?

Mysqld進程打開的文件句柄數(shù)：
lsof（list open files）是一個列出當前系統(tǒng)打開文件的工具。

[root@db11149 ~]# lsof -p 24504 | wc -l 
4805

沒有超過MySQL設(shè)置的限值。

查看操作系統(tǒng)的日志：

localhost kernel: VFS: file-max limit 65536 reached
localhostnrpe[6665]: Network server accept failure (23: Too many open files in system)

日志顯示操作系統(tǒng)的連接數(shù)已經(jīng)達到了最大值65535了，但是服務(wù)器上運行的業(yè)務(wù)應(yīng)用只有數(shù)據(jù)庫服務(wù)，而mysql打開的文件句柄數(shù)不到5000個。因此推斷是有哪個正在運行的服務(wù)打開的句柄數(shù)過多導致的。

顯示shell中的資源限制：
ulimit命令修改的數(shù)值只對當前登錄用戶的目前使用環(huán)境有效（只對當前會話有效）,系統(tǒng)重啟或者用戶退出后就會失效.

[root@db11149 ~]# ulimit -a
core file size (blocks, -c) 0
dataseg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 268288
max locked memory (kbytes, -l) 32
max memory size (kbytes, -m) unlimited
open files (-n) 65536
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 268288
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited

?

對所有會話永久生效，修改limits.conf：

[root@db11149 ~]# cat /etc/security/limits.conf | tail -3
# End of file
* soft nofile 65536
* hard nofile 65536

?

這個當中的硬限制是實際的限制，而軟限制，是warnning限制，只會做出warning.其實ulimit命令本身就有分軟硬設(shè)置，加-H就是硬，加-S就是軟
默認顯示的是軟限制，如果運行ulimit命令修改的時候沒有加上的話，就是兩個參數(shù)一起改變.

查看目前運行的所有進程打開的句柄數(shù)：

# fori in `ps -ef| egrep -v 'UID PID PPID' | awk '{print $2}'` ; do echo "pid=$i, open_files=`lsof -p $i | wc -l`" >>1 ;done
pid=27644, open_files=35
pid=27646, open_files=35
pid=27647, open_files=7614
pid=27648, open_files=7614
pid=27649, open_files=7666
pid=27650, open_files=7379
pid=27651, open_files=7479
pid=27652, open_files=7214
pid=27653, open_files=7916
pid=27654, open_files=7804

#for i in `ps -ef| egrep -v 'UID PID PPID' | awk '{print $2}'` ; do echo "open_files=`lsof -p $i | wc -l` &&& whole=`ps -ef | awk '{if($2=="'"$i"'"){print $0}}'`" ;done

查看打開句柄數(shù)最多的進程：

確定是zabbix進程打開的

[root@db11149 ~]# ps -ef | grep zabbix
root 27644 1 0 Jul27 ? 00:00:00 zabbix_agentd -c /etc/zabbix/zabbix_agentd.conf
root 27646 27644 0 Jul27 ? 00:00:00 zabbix_agentd: collector [idle 1 sec] 
root 27647 27644 0 Jul27 ? 00:02:06 zabbix_agentd: listener #1 [waiting for connection]
root 27648 27644 0 Jul27 ? 00:02:06 zabbix_agentd: listener #2 [waiting for connection]
root 27649 27644 0 Jul27 ? 00:02:07 zabbix_agentd: listener #3 [waiting for connection]
root 27650 27644 0 Jul27 ? 00:02:04 zabbix_agentd: listener #4 [waiting for connection]
root 27651 27644 0 Jul27 ? 00:02:06 zabbix_agentd: listener #5 [waiting for connection]
root 27652 27644 0 Jul27 ? 00:01:59 zabbix_agentd: listener #6 [waiting for connection]
root 27653 27644 0 Jul27 ? 00:02:09 zabbix_agentd: listener #7 [waiting for connection]
root 27654 27644 0 Jul27 ? 00:02:07 zabbix_agentd: listener #8 [waiting for connection]

?

產(chǎn)生原因

重啟zabbix agent后，打開的文件被釋放。

https://support./browse/ZBX-9251

由此確定是由于zabbix agent的異常導致的。

?

如何處理
查找zabbix的資料后確定是zabbix agent的BUG，目前在zabbix agent 2.4.3和2.4.4版本中發(fā)現(xiàn)了這個BUG，在2.2和2.5版本中已經(jīng)修復了。
然后更新zabbix agent的版本。

?