一次虚拟机性能问题导致的应用故障

最近我负责维护的一套语音平台出了问题。故障现象据客户反馈是转入IVR以后没有正常响应，客户无奈挂机了。

老实说，刚开始接到用户反馈的时候，我是不太相信的。我们的系统平时运行运行很稳定，客户的并发数不大，系统的硬件配置也挺高，遇到这样的问题还是“头一遭”！我甚至都怀疑又是上游系统的管理员推卸责任，“诬赖”我们系统（这事真不能怪我有想法，真是上游系统的管理员多次找我“麻烦”，系统一有异常就说我们的系统有问题，可实际上往往都是他自己平台的原因）。

谨慎起见，我还是远程登录，查了一下系统内置的通话记录（CDR）。出问题的时间段，有相同号码多次呼入系统，但是通话时间极短（10s以下），计费时长为0，挂机原因是“ORIGINATOR_CANCEL”，不像是正常通话；而在系统恢复时间点之后，该客户还有1次相对“够长”时间的语音呼入，应该是能电话沟通了，挂机原因也是正常的“NORMAL_CLEARING”。由此看来，我们的语音系统当时真地出现故障了！

我用less命令看了下故障当日的FS历史日志，确实在客户反馈的时段确实出现了多次“Socket Error”错误！用grep命令过滤“Socket Error”这个关键词，发现最近一段时间都有间歇性报这个错误。

仔细再检查了一下FS日志，我发现故障时段的“Socket Error”报错往往伴随着“socket(127.0.0.1:9000 async full)”和“Trying host: 127.0.0.1:9000”的错误。显然这是“Socket Error”的真实原因——FS连接本机的9000端口失败了！

9000这个端口的服务正是IVR Service提供的，要找到这次故障的具体原因还需要继续排查。

查看当天IVR服务的错误日志（Error log），我发现当时应用报了“JdbcConnectionException：Failed to obtain JDBC Connection”异常——应用程序连接数据库（mysql）错误。IVR应用连接不上mysql数据库，做不了CRUD操作，报出连接失败的错误，导致应用本身和上游的FS出错——这很正常。

继续检查mysql的错误日志。在当天故障时间段，相关的mysql日志有“InnoDB: page_cleaner”相关的一些异常信息。

查询deepseek“mysql的InnoDB page_cleaner会导致数据库连接失败吗”？deepseek回答：“是的，InnoDB的page_cleaner线程间接导致数据库连接失败是一个在生产环境中并不少见的问题，但它通常不是根本原因，而是更深层次问题的一个症状……因为刷脏本质是一个I/O操作……”。

至此，我确认需要检查一下服务器的IO使用情况，但是这台服务器上并没有安装iostat程序，而且服务器还不能上网。于是我找了一台能够上网的服务器，使用apt download命令下载了iostat程序的安装包，然后再用scp命令复制到这台服务器，最后用dpkg -i命令手动安装iostat程序包。

我用iostat -x /dev/vda3命令检查了一下服务器根目录所在的vda3的磁盘性能，发现不仅仅是磁盘使用率经常达到100%，平均等待队列也频频超过1，vda3的磁盘表现确实“拖后腿”了！

虚拟机服务器基础性能方面的问题就不在我的责任范围之内了，所以我把这个结论反馈给了负责这个项目的项目经理，由他再去和相关人员沟通讨论下一步的处理办法吧。这一次的故障排查就到这里了。

最后解释一下我为什么判断mysql故障是导致此次IVR连接异常的原因。1是根据调用关系。各子系统之间的关系示意如下：

FS和IVR都是中间层，都有“承上启下”的调用关系，而MySql是最终调用层，如果它表现异常，调用它的上层子系统都会受到影响。

2是根据日志中的报错时段。在FS和IVR日志中，类似“Socket Error”或者“JdbcConnectionException”的错误一直在持续，并不限于上述问题时间段（至少说明系统一直在“带病”工作），但是MySql出现“InnoDB page_cleaner”的报错时点则和此次问题的故障时间基本一致，进一步证实了MySql问题是导致本次故障的根本原因。