我们有一个服务器运行时间特别慢的问题，但CPU永远不会很高。 一个系统pipe理员已经研究过这个问题，并说任何时候都有大量来自服务器A的MySQL端口（服务器A运行正常）和服务器B（服务器B）之间的连接。 在服务器B上看到的主要症状是非常缓慢的页面加载时间，主要是由页面执行任何操作之前的初始化挂起，以及与Shell的连接缓慢。 其值得指出的不是网站/应用程序特定的 – 不是由Javascript或类似的东西引起的，因为我们有3个或4个其他同规格的服务器运行相同的应用程序，没有任何问题。
我想要做的是试着追踪这两个服务器之间的MySQL连接的确切性质。 所以，来源是什么，目的地是什么，目的是什么。 我应该看看启用（当前禁用）通用日志？ 有什么我可以尝试吗？ 这两个服务器都运行CentOS（一个在4.8，一个在5.5），最新版本的WHM / cPanel和最新稳定的PHP / Apache版本。
谢谢。
启用日志是一个好主意，您也可以使用MySQL Administrator客户端查看打开的连接，并查看您遇到问题时所做的操作。
尽pipe从描述中我可以想到一个非常常见的问题，那就是在处理传入连接之前导致MySQL等待DNS超时的DNS问题。 这通常体现在您为应用程序为每个请求打开一个新的MySQL连接（而不是使用持久连接池）的情况下所描述的内容。
阅读更多关于这里： http : //dev.mysql.com/doc/refman/5.0/en/dns.html
（my.cnf中的skip_name_resolve是IIRC的选项）
如果你有两台服务器连接，并且你的连接速度很慢，但是一旦线程连接速度很快，我就怀疑远程主机的dnsparsing可能会导致问题。
skip-name-resolve 在[mysqld]部分的/etc/mysql/my.cnf（或同等文件）将阻止这些DNS查找。
确保您的授权是使用IP而不是主机名完成的。
你也可以尝试使用较less侵入性的方法[没有启用性能开销的日志]。 使用tcpdump嗅探stream量[您可以在连接的任何一端或中间 – 在某个路由器或端口镜像的可pipe理交换机上]执行此操作。
tcpdump -s 1600 -w dump.cap -i eth0 host 10.1.2.3 and port 3306
分析dump.cap – 首先用wireshark [在这个阶段，你应该能够判断是否有足够的并行连接]，如果需要的话 – 看看mk-query-digest ，这可以让你很好地洞察来自mysql日志或tcpdump的stream量。