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

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

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

Возникает повторяющаяся проблема, вызывающая сильное замедление работы кластера, обычно на 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. Я попробовал комбинацию всех узлов, чтобы убедиться, что один конкретный узел влияет на все остальное: проблема всегда присутствует, независимо от того, какой узел я отключаю или использую. Проблема всегда связана с количеством одновременно активных узлов.

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

Связанный контент