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

У меня есть 5 выделенных серверов (идентичные машины: 32 ядра, 96 ГБ ОЗУ, SSD-диски в 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. Я попробовал комбинацию всех узлов, чтобы убедиться, что один конкретный узел влияет на все остальное: проблема всегда присутствует, независимо от того, какой узел я отключаю или использую. Проблема всегда связана с количеством активных одновременно узлов.

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

0 ответов

Другие вопросы по тегам