网络基本功(二十九):Wireshark抓包实例诊断数据库常见问题

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

介绍

通常来说,数据库,应用和网络在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)。

image002.jpg

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

image003.jpg

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

  2. 这种情况下,应当与DBA讨论怎样大幅减少网络上传输的报文数量,或是改变终端服务器或网络接入的方式。

  • 另一个可能发生的问题是抓包文件反映出有软件问题。以下截图中可看到5个重传(1),并且客户端打开了一个新的连接(3)。看起来像一个TCP问题但只发生在软件中一个特定窗口。这只是由于一个软件进程停止运行,因此TCP无法对客户端作出响应(2)。

image004.jpg

更多建议:

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

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

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

参考

Network Analysis Using Wireshark Cookbook

原文: https://wizardforcel.gitbooks.io/network-basic/content/28.html