透过现象看本质，用APM数据库问题

版权声明：本文为神州灵云作者的原创文章，未经神州灵云允许不得转载。

本文作者：Lu

一个好的软件系统必定给用户好的体验，但是事与愿违的是大家在浏览网页的时候经常会遇到页面响应慢，卡死现象，造成这种现象的原因有很多，有程序原因，有网络原因，也可能是服务器资源配置不合理造成的,对于软件开发维护者来说，如何迅速的通过故障现象定位问题的本质，并及时解决问题是至关重要的，本人从事于APM产品研发，下面就软件的角度分析其中一个很常见的原因，由于数据库响应慢造成的系统反应慢。

先简单的描述一下故障现象，有用户反应网站部分页面响应时间在30秒以上，严重影响体验。反馈给厂家，对应用及网络进行排查后，均未发现异常。

遇到这种问题，研发部不懂网络专业知识，网络部不懂程序代码，在各自的领域都发现不了问题，那么问题究竟在哪里呢，这个时候就需要用一款好的apm产品来直观精准的定位问题，用数据说话，用事实证明，于是厂家采用apptrace产品进行系统监控，数据如下：

请求响应慢的页面，采集的响应时间在30秒以上，与故障现象一致，进一步查看每一个请求的代码级调用：

响应慢的页面都访问了mysql数据库，而且耗时也就基本在数据库这一块，研发人员根据这一信息进一步分析是数据库mysql采用默认部署，应用及数据库主机名都采用默认主机名（localhost.localdomain），并没有修改主机名，数据库未进行优化配置。Mysql数据库在默认安装时，数据库对所有的访问会进行反向域名解析，由于解析异常，连接超时后，才会进行正常连接，因此影响了用户访问页面的性能。解决的方法也很容易，通过修改数据库服务器数据库配置文件/etc/my.cnf，增加skip-name-resolve字段，关闭反向域名解析，故障解决。

通过apptrace平台数据可以看到优化后的页面请求情况，从优化前的61秒降低到19毫秒，之前缓慢页面的响应时间也大幅降低。

用户再次访问系统时，系统页面响应非常快速，再未出现卡顿现象。

通过这个案例分享给大家排查系统缓慢的分析思路，如果系统整体都慢，需要考虑资源使用情况，是否是内存资源分配不合理导致fullgc问题，如果是某些页面慢首先想到的就是数据库有没有问题，由于数据库导致系统缓慢一般有如下几个原因，上面只是其中一个，其他原因如：一次业务请求过多的调用数据库操作，数据库连接数太少导致请求排队，频繁查询或大量关联查询时未设置索引或者索引不合理等，具体是哪一种原因需要根据现象具体分析，在分析问题中合理借助apm产品工具，必将起到事半功倍的效果。