Повторяющиеся блокировки и замедления в кластере Percona XtraDB

У меня есть 5 выделенных серверов (идентичные машины: 32 ядра, 96 ГБ ОЗУ, твердотельные накопители в RAID и гигабитное соединение Ethernet), настроенных с помощью Percona XtraDB Cluster.

Возникает повторяющаяся проблема, вызывающая серьезное замедление работы кластера обычно на 30–60 секунд, но иногда он «зависает» на срок до 5–10 минут.

Система используется для загруженной сети веб-сайтов, и я использую mysql-proxy на каждом веб-сервере для балансировки нагрузки трафика в базу данных.

Проблема отсутствует, если включен только один узел. Вместо этого с каждым добавленным узлом проблема возрастает в интенсивности (количество времени, в течение которого запросы замедляются / блокируются), пока она не становится очень невыносимой с 4 активными узлами (кластер в этот момент больше не может восстанавливаться автоматически).

Вот подробные симптомы:

1. Каждые 5–15 минут все запросы на запись (INSERT / UPDATE) застревают в очереди каждого узла. Некоторые запросы отправляются через 45-50 секунд, а другие полностью зависают.
2. В большинстве случаев через 30–60 секунд кластер каким-то образом может наверстать упущенное и быстро отправляет запросы в течение 1-2 секунд.
3. Иногда кластер не может автоматически обрабатывать эти зависшие запросы, и мне нужно вручную отключить самые загруженные веб-сайты, чтобы снизить нагрузку и после 30 секунд отсутствия нагрузки кластер снова сможет отправлять все запросы.

4. Журналы ошибок обычно чистые, без сообщений об ошибках до или после замедления. Редко я получаю что-то подобное (может, 1 раз из 10):

   130906 9:53:27 [Примечание] WSREP: (3f3abd42-15bc-11e3-b38b-2e049b972e3b, 'tcp: //0.0.0.0: 4567') включение запроса ретрансляции сообщений, неактивные узлы: tcp: // IPOFONEOFTHENODES

   130906 9:53:27 [Примечание] WSREP: (3f3abd42-15bc-11e3-b38b-2e049b972e3b, 'tcp: //0.0.0.0: 4567') отключение запроса реле сообщений

5. У меня обычно wsrep_cert_deps_distance около 400 при нормальной нагрузке. Как только начинается замедление, wsrep_cert_deps_distance медленно увеличивается до диапазона 2k-3k (когда он достигает отметки 3k, мне нужно вручную отключить приложение, иначе кластер не сможет восстановиться самостоятельно)

6. Мониторинг с помощью mytop и atop Я не замечаю высокой нагрузки на сервере или в процессе mysql. Загрузка ЦП всегда достаточно низкая (около 25% от максимальной) как во время нормальной работы, так и во время замедления. Использование ввода-вывода в порядке, много свободной оперативной памяти, vmcom ниже лимита.

Я использую myq_status для мониторинга кластера на каждом узле в реальном времени, и вот что происходит:

• Переменная wsrep_flow_control_paused всегда равна 0,0, даже когда происходит замедление.
• Никаких ошибок wsrep_local_bf_aborts или wsrep_local_cert_failures не происходит.
• На каждом узле исходящая репликация обычно равна 0 и увеличивается до 200-300, когда происходит замедление.
• Входящая репликация всегда равна 0 на каждом узле (редко 1, но это происходит даже при нормальной нагрузке). Это меня озадачивает, поскольку, по-видимому, в кластере нет медленного узла.
• Через 10-15 секунд с начала замедления отправленные и полученные операции и байты становятся 0 на каждом узле. Они остаются на 0 в течение одной или двух секунд, затем в следующую секунду происходит увеличение количества операций и байтов, в сочетании с большим количеством операций "oooe" (выполнение вне очереди). Это повторяется каждые несколько секунд, пока сервер не вернется к нормальный.

Вот подробности тестов, которые я провел, чтобы попытаться устранить проблему (безуспешно ...):

1. Сначала я проверил сеть: серверы находятся в одной стойке с выделенной гигабитной сетью, и, похоже, все работает нормально, без потери пакетов или других явных проблем с сетью.
2. Я проверил использование полосы пропускания: каждый узел использует в среднем от 30 до 100 Мбит / с (мегабит) полосы пропускания. Я проверяю в реальном времени с помощью «iftop», и пока возникает проблема, использование полосы пропускания обычно ниже среднего (от 15 до 30 Мбит / с). При синхронизации пропускная способность узла увеличивается до 800-900 Мбит / с (как и должно быть), поэтому я не думаю, что сеть переполнена.
3. Я попробовал комбинацию всех узлов, чтобы убедиться, что один конкретный узел влияет на все остальное: проблема всегда присутствует, независимо от того, какой узел я отключу или использую. Проблема всегда связана с количеством узлов, активных одновременно.

Кто-нибудь когда-нибудь сталкивался с подобной проблемой? Заранее спасибо!