Cetus中间件简介
Cetus是网易乐得公司开发的mysql中间件，有读写分离和分片两个版本。读写分离版将前端发来的读请求和写请求分别发送到不同的服务器后端，提高数据库的处理能力；分片版支持对后端的数据库进行分库，可以根据hash/range方式对大表进行分布式部署，提升系统整体的响应和容量。
前两天遇到一个诡异的问题，应用连接cetus中间件会一直hang住。用mysql客户端连接中间件同样连不上，也不返回报错，假死状态。多亏了sa组大牛何伟同学相助，几经周折才解决。在测试环境重现这个问题，把当时解决问题的思路总结一下。
查看cetus运行日志和os系统日志，均没有有用信息，从系统资源使用、IO使用、网络宽带、运行队列和swap使用情况、CPU资源使用率等几个方面着手排查。
cetus进程的cpu使用率接近100%，由于cetus中间件是单进程的，100%的cpu使用率是极限值，证明cetus已经相当繁忙。
执行iostat –xm 2 查看IO使用情况
所有磁盘%util使用率都不高，不是磁盘的问题
最近2秒内，平均发送、接收、总流量都不高，都在每秒5M以内，虚拟机网络流量不大。
执行vmstat指令，查看运行队列及swap使用情况
从结果上看，运行队列一直大于0，阻塞进程为0；没有使用swap，si和so都是0.
从资源使用率上看，只有cpu使用率比较高，那就从cpu使用率下手，用火焰图分析一下cpu都在干什么。
火焰图用于查看程序资源占用情况，以图形的形式展现结果，由于其外表看起来像一团火焰，故命名为火焰图。通过观看水平条的宽度来区分占用资源的操作，条越宽，说明占用的资源越多，越需要关注或优化。
收集数据并生成火焰图
cd ~/nginx-systemtap-toolkit
#监控pid为 2690的进程30s
./sample-bt -p 2690 -t 30 -u>../cetus_3999.bt
cd ~/FlameGraph/
./stackcollapse-stap.pl ../cetus_3999.bt>../cetus_3999.cbt
#生成火焰图文件cetus_3999.svg
./flamegraph.pl ../cetus_3999.cbt>../cetus_3999.svg
生成的火焰图使用浏览器打开
火焰图显示，accept4，network_socket_free，network_socket_new占用的资源很多，而这三个模块又跟网络相关，怀疑还是网络的问题。既然如此，用tcpdump抓包看看。cetus端口为3999，在虚拟机用root用户开启抓包
tcpdump -i any tcp and port 3999 -c 400000 -w tcpdump_3999.pcap
抓到的信息很少，也没有收获。
以上方法还是找不到问题所在，只能另辟蹊径：用strace跟踪cetus进程执行时的系统调用和所接收的信号。
strace -c -p 2690
从上图可以看出，accept4占了26.68%的时间，期间有73457个报错。
再看一下strace的具体输出
strace -p 2690-o strace.log
2690为cetus的进程号，把strace追踪的信息达到strace.log文件
可以看到accept4很多Too many open files的报错，出现这句提示的原因是程序打开的文件/socket连接数量超过系统设定值。
去检查一下安装cetus的系统用户可打开的文件数量
ulimit -a
mysql-cetus用户可以打开6万多的文件数量，一般这个值是够用的。
再看看cetus的配置文件
最大可打开文件数为18
通过lsof查看cetus已经打开的文件数量
lsof -p 2690|grep -v mem|wc –l
数量为22，22个已打开的文件数量中有4个不占用max-open-files的名额。
那么把cetus中间件的参数文件max-open-files值调为1024，重启中间件程序，用客户端就可以登录中间件了，再次查看打开的文件数
lsof -p 3490|grep -v mem|wc –l
数量为23，cetus进程打开的文件数增加1
中间件配置max-open-files的值太小，当有新的连接请求时，cetus无可用的文件，无法响应外部的连接请求，最终导致客户端无法连接到中间件。
系统和中间件的参数一定要根据实际情况，配置正确的值；中间件也做出调整，把类似Too many open files的错误信息打到cetus运行日志，方便使用者诊断问题。在这个案例里，如果直接用strace追踪中间件的输出，可以更快的知道问题所在。
