Percona XtraDB群集上的重复性locking和减速

Percona XtraDB集群configuration了5台专用服务器（相同的机器：32个内核，96GB RAM，RAID中的SSD驱动器和千兆以太网链路）。

有一个反复出现的问题，导致群集的严重下降通常约30到60秒，但有时会被卡住达5-10分钟。

该系统用于繁忙的网站networking，我使用每个networking服务器上的mysql-proxy来负载均衡stream量到数据库。

如果仅启用一个节点，则问题不存在。 每增加一个节点，问题就会增加（查询放慢/locking的时间），直到4个节点处于活动状态（此时群集不能自动恢复）变得非常难以忍受。

• 如何在自定义前缀下安装jemalloc来编译MySQL（Percona）？
• mysqladmin没有等待完全closures（或debian的init.d脚本坏了？）
• Percona：写通信数据包时出错
• 不能在centos 6.5上安装mysql-devel
• 无法将节点添加到Percona XtraDB群集

以下是详细的症状：

1. 每5到15分钟，所有的写入查询（INSERTs / UPDATEs）都会卡在每个节点的队列中。 一些查询在45-50秒之后发送，而另一些则完全停顿。
2. 大多数情况下，在30到60秒之后，集群能够以某种方式赶上，并在1-2秒内迅速发送查询。
3. 有时候，集群不能自动处理这些卡住的查询，我需要手动禁用最繁忙的网站，以便降低负载，在没有负载的30秒后，集群再次能够发送所有查询。

4. 错误日志通常是干净的，在发生减速之前或之后没有错误消息。 我很less得到这样的东西（可能是10次中的1次）：

   130906 9:53:27 [注意] WSREP：（3f3abd42-15bc-11e3-b38b-2e049b972e3b，'tcp：//0.0.0.0：4567'）转向消息中继请求，nonlive peers：tcp：// IPOFONEOFTHENODES

   130906 9:53:27 WSREP：（3f3abd42-15bc-11e3-b38b-2e049b972e3b，'tcp：//0.0.0.0：4567'）将消息中继请求closures

5. 在正常的负载下，我通常会有大约400的wsrep_cert_deps_distance。 一旦减速开始wsrep_cert_deps_distance慢慢增加，直到2k-3k范围（当它达到3k标记我需要手动禁用应用程序或集群不能自行恢复）

6. 用mytop和atop监视我注意到在服务器或mysql进程中没有高负载。 在正常运行和减速期间，CPU使用率总是相当低（约为最大值的25％）。 I / O使用情况良好，充足的RAM免费，vmcom的限制下。

我使用myq_status来实时监控每个节点上的集群，这就是发生了什么事情：

• 即使发生减速，wsrep_flow_control_pausedvariables始终为0.0。
• 没有发生wsrep_local_bf_aborts或wsrep_local_cert_failures。
• 在每个节点上，出站复制通常为0，并在发生减速时增加到200-300。
• 入站复制在每个节点上始终为0（很less为1，但即使在正常负载下也是如此）。 这让我感到困惑，因为显然在集群中没有缓慢的节点。
• 从减速开始10-15秒之后，发送和接收的操作和字节在每个节点上变为0。 他们停留在0一两秒钟，然后增加的操作和字节在下一秒发生，再加上大量的“oooe”操作（乱序执行），每隔几秒重复一次，直到服务器返回正常。

以下是我执行的testing的详细信息，以尝试解决问题（没有任何运气…）：

1. 我首先检查了networking：服务器与专用千兆networking在同一个机架上，一切似乎都正常，没有丢包或其他明显的networking问题。
2. 我检查了带宽使用情况：每个节点平均使用30到100mbps（兆字节）的带宽。 我使用“iftop”实时检查，发生问题时带宽使用率通常低于平均水平（15至30mbps）。 同步节点带宽高达800-900mbps（因为它应该是），所以我不认为networking饱和。
3. 我尝试了所有节点的组合，以确保一个特定的节点影响到其他所有事物：无论我禁用或使用哪个节点，问题始终存在。 问题总是与同时活动的节点数量有关。

有没有人遇到类似的问题？ 提前致谢！