Mysql应用性能监控案例分析

背景介绍

某企业开发环境用户反应，在相同的机房，相同网段，不同IP地址的mysql服务器，相同访问，一个响应很快，一个明显的慢。

纳闷之余，网深科技工程师帮其分析了原因。

分析之前，先约定一下，以下对响应快的简称“很快”，响应慢的简称“很慢”吧。

故障描述

在查看了用户使用mysql连接测试这一操作的演示，的确存在诸如用户的描述的现象。如下：

从用户操作层面，的确存在明显快慢差别，后者让人无法接收，“很慢”的确很慢。

问题分析

接下来， 进入信息采集，侦察分析阶段。

客户端抓包分析

在客户端电脑，分别采集了很快和很慢以上操作的报文信息。结论如下。

我是很快客户端的报文

从很快客户端数据看，三步握手后，服务器更新了一下窗口，然后在0.05秒后返回了数据库版本信息。继而后续交换较快，整个连接持续1.2秒时长。

我是很慢客户端的报文

下面看一下很慢同学的表现。

同样，三步握手后，服务器更新了一下窗口信息。

接下来发生了一个异常现象，服务器在22秒后，才发送过来版本信息。

整个连接时长约27秒。

通过比较看到，很慢同学的确很慢。相同操作一个是1.2秒，一个是27秒。

服务器端抓包分析

从上述分析看到，很慢同学网络连接建立时间很快，慢的主要原因是服务器响应回来的信息时间太长。

那么，站着服务器角度，比较分析一下，是否可能由于某些网络因素导致了很慢的存在。

我是很快服务器的报文

在很快服务器上采集数据，从下图看到，第四个未携带数据的ack更新窗口包和第五个payload报文（数据库版本信息）之间时间差约0.008秒。

我是很慢服务器的报文

同样，在很慢服务器上，更新窗口包和数据库版本包之间，时间差约22秒。的确很慢。

抓包分析结论

通过上述在客户端和服务器端的对比分析看到，很慢同学慢的原因是，服务器本身发出报文的时间很长，约22秒。

因此，通过抓包分析的结论是，很慢的原因是服务器的原因，与网络无关。

进一步问题分析

一般情况下，如果是网络运维部门，问题分析到这里，基本就可以停止了，然后理直气壮的把球踢给系统部门，哼，这问题不是我的原因。

而网深科技的技术人员，为了表现出自己的真才实学，带着打破砂锅问到底精神，还想进一步探索，为什么会有这种现象出现？

于是，有了进一步问题分析的环节。

细节决定成败。

在前面服务器抓包分析中，从服务器本身抓包信息来看，服务器本身的IP地址并没有显示为数字格式。与mysql通讯的地址显示如下。

很快：demo.cloudinside.com.cn.mysql

很慢：Dev1.NAPM.mysql

既然发现了2者的不同之处，先使用简单的ping命令，尝试一下，看看返回结果。

从最简单的ping着手，以下是在2台服务器内部ping的结果。

我是很快服务器的ping

很快同学ping结果很快出现，名称解析失败，结果是Unknown host，如下图。

我是很慢服务器的ping

很慢同学ping结果很慢出现，约20秒。结果是Host name lookup failure，主机名解析失败。

从DNS配置信息入手，下面检查2台服务器DNS配置信息。

我是很快服务器的DNS

查看很快服务器DNS，显示有多个namesever。

我是很慢服务器的DNS

但很慢服务器的DNS却没有配置，如下。

解决问题

通过上述分析，已找到很快和很慢两者的差异。下一步，尝试解决问题，通过给很慢配置DNS信息，再做一下ping操作，看看结果。

很慢服务器配置DNS

为很慢服务器配置DNS信息，内容与很快服务器一样。

如下图。

很慢服务器ping操作

接下来，再操作一次ping命令。

发现很快返回信息，结果和很快服务器一样，为Unknow host。

问题验证

通过上述分析和配置后，再次对很慢同学进行mysql连接测试，速度飕飕的，它终于不再饱受埋怨了。

以下是很慢成为了很快的见证。

整个连接时长1.13秒。

问题解决。