网络基本功（二十九）：Wireshark抓包实例诊断数据库常见问题

转载请在文首保留原文出处：EMC中文支持论坛https://community.emc.com/go/chinese

介绍

通常来说，数据库，应用和网络在IT架构中处于不同的分支。数据库的故障排查由DBA来完成，但是网络工程师仍可以从抓包中定位出问题并不出自网络。当IT抱怨“网速慢”，实际并不一定是这样。下文帮助我们验证所谓“网速慢”的问题。

更多信息

工作过程:

对于数据库问题，按照以下步骤：

当怀疑是“慢速网络响应”时，问以下问题：
- 问题发生于本地还是全局？是只发生在远端办公室，还是center也有发生？如果整个网络都出现问题，就不会是WAN带宽问题。
- 对于所有客户端是否都发生了这样的问题？如果只是某些特定用户碰到问题，则可能是这些用户运行了某些应用导致。
- 客户端和服务器之间通讯链路是否过载？导致过载的应用是什么？
- 是所有应用都运行缓慢，还是使用特定数据库的应用运行缓慢？是PC比较老旧，还是服务器资源耗尽?
搞清楚上述问题之后，开始故障排查：

1. 打开Wireshark开始抓包。可以将对端端口连到PC，服务器，VLAN，或连接远端客户端的路由器。

2. 在expert info中查看TCP事件。这些事件发生在整个通信链路，或是特定的IP地址，还是特定的TCP端口？此操作能够帮助定位问题并验证是否发生于特定链路，服务器，或是应用。测试连接到Internet的数据流时，可能会得到发往站点或mail server（诸如此类）的很多重传以及重复ACK。在组织内部，重传范围应当在百分之0.1至0.5。连接到Internet时，可能会高得多。
当你看到网络上有问题时，按照前几张的故障排查步骤给予解决。但是，也有些网络问题会影响数据库操作。下例中，可看到客户端与服务器通信链路往返延时达到35至40ms。

1. 我们查看TCP stream 8（1），连接开始于TCP SYN/SYN-ACK/ACK。如下图（2）所示。可以看到整个连接花费了371个报文（3）。

2. 连接继续，可见到DB请求与响应之间时间间隔大约35ms。

3. 由于往返已经有371个报文，371X35 ms大约是13秒。加上可能发生一些重传导致延时，用户查询一次数据库可能要等待10至15秒。

4. 这种情况下，应当与DBA讨论怎样大幅减少网络上传输的报文数量，或是改变终端服务器或网络接入的方式。
另一个可能发生的问题是抓包文件反映出有软件问题。以下截图中可看到5个重传（1），并且客户端打开了一个新的连接（3）。看起来像一个TCP问题但只发生在软件中一个特定窗口。这只是由于一个软件进程停止运行，因此TCP无法对客户端作出响应（2）。

更多建议：

右键数据库客户端与服务器会话报文，会打开一个窗口，有助于DBA查看网络问题。当碰到延时问题时，例如，通过移动电话接入Internet，数据库客户端到服务器的通讯可能效率低下。可能需要切换接入方式。

很重要的一点是搞清楚数据库的工作模式。如果客户端正在接入数据库服务器，数据库服务器正在使用从另一台服务器共享的文件，可能客户端——服务器工作良好，但问题可能出在数据库服务器与文件服务器之间共享文件上。确保在开始测试之前确知所有依赖条件。

最重要的是，与DBA保持良好关系。

参考

Network Analysis Using Wireshark Cookbook