Периодические проблемы с производительностью KVM, вызывающие сбои производительности

В настоящее время мы работаем на хостинг-провайдере, который позволяет нам настраивать несколько виртуальных машин с использованием KVM, где каждая виртуальная машина работает на своем собственном физическом сервере (то есть: один гипервизор, одна виртуальная машина со всей выделенной ей памятью и ЦП). Недавно мы столкнулись с некоторыми неприятными проблемами, которые нам нужно было диагностировать (оказались переполнением стека - lol). В процессе мы настроили DataDog для мониторинга всех наших серверов, и это помогло нам сузить причину и в конечном итоге исправить ее. Но мы нашли это очень полезным, мы оставили все включенным. В процессе изучения инструментов мы постоянно наблюдаем медленное время отклика в течение дня для наших веб-сайтов. Включив трассировку APM, мы смогли сузить ее до плохого времени ответа от нашего кластера MySQL. Иногда мы видим, что для создания MySQL-соединений требуется 900 мс или больше, а в других случаях мертвые простые запросы, такие как настройка параметров сортировки соединений или часового пояса, занимают 600 мс или более. Запросы, которые обычно выполняются менее чем за 800 микросекунд.

Чтобы диагностировать проблему, мы настроили эхо-запросы к нескольким конечным точкам в нашем кластере и получили два пинга, которые регулярно выполняются медленно (иногда 4-5 с!), Которые просто регистрируют, но возвращают строку (версия PHP / apache) или возвращают некоторый клиентский IP информация (версия .net и IIS). Мы настроили их, чтобы увидеть, увидим ли мы проблемы в Linux или IIS без каких-либо дополнительных действий, и мы это делаем. Как ни странно, в то время, когда мы получаем эти сбои, ЦП на машинах очень низкий, то же самое и в кластере MySQL. Когда запросы выполняются медленно, ЦП очень низкий, так как эти блоки обычно занимают около 5-6% ЦП большую часть времени.

Чтобы попытаться выяснить, была ли это проблема с сетью, мы настроили захваты с помощью Wireshark в окнах и выгружали пакеты, в то время как у нас были некоторые украшения в запросах, чтобы мы могли легко найти их в дампе пакетов (в основном устанавливаем переменную MySQL в запрос, представляющий собой закодированную версию текущей метки времени в формате UTC в микросекундах). Используя это, мы смогли правильно сопоставить длинные промежутки MySQL в DataDog APM с пакетами в дампе TCP. Глядя на сторону Windows / IIS, мы могли видеть, что все время было потрачено на ожидание, пока результат вернется по сети с сервера MySQL. Таким образом, время, указанное в DataDog для запроса MySQL, точно совпадало со временем в дампе данных.

Как вы можете видеть из двух снимков экрана, они точно совпадают. Чтобы определить, возникла ли проблема с сетью на стороне MySQL, мы снова сделали тот же дамп захвата на машине Linux и увидели то же самое. MySQL получил запрос и через огромное количество миллисекунд отправил ответ. Таким образом, проблема явно не в сети, а в том, что заставляет сам MySQL замедляться.

Что действительно странно, так это то, что блокируется не сам MySQL, потому что конкретный ящик, к которому я запускал эти запросы, выполнял только запросы чтения с одной из наших виртуальных машин Windows в качестве ведомого устройства чтения. Таким образом, он не имел большой нагрузки, и во время запросов загрузка ЦП составляла, вероятно, 3% (у него 16 физических ядер ЦП с двумя ЦП 8C Xeon и 32 виртуальных ядра, выделенных виртуальной машине). Таким образом, очевидно, что это не проблема загрузки сервера MySQL, и, что более важно, из дампов TCP становится ясно, что хотя запрос, который нас интересовал, занимал много времени для выполнения, появилось множество других запросов из других подключений, которые были обработаны без задержка.

Теперь, в довершение всего, мы также обнаружили в нашем журнале, что подчиненное устройство MySQL обычно сильно отстает, на 30-40 секунд позади главного. Мы видели случаи, когда он отставал от материнской платы на 110 секунд, что не имеет смысла, поскольку машина имеет низкую нагрузку на нее, и все это находится в той же локальной частной сети, что и основная база данных (и веб-серверы). Иногда эти задержки в ведомом устройстве происходят примерно в то же время, когда происходят замедления, а иногда - нет.

Итак, теперь, когда мы окончательно определили, что не думаем, что это проблема сети, мы начинаем думать, что это какая-то проблема блокировки потоков в самом KVM? Тем более, что мы видим очень странные замедления на всех наших виртуальных машинах, некоторые из которых не имеют ничего общего с MySQL (например, статический файл приветствия PHP). Поскольку у нас нет никакого контроля над уровнем KVM, поэтому мы не знаем, на какой версии он работает, и как он настроен. Но чем больше мы изучаем эти сложные проблемы, тем чаще мы указываем на KVM как на основную причину этого, но мы не знаем, как ее решить.

Чтобы проиллюстрировать проблему, вот проверка связи PHP-страницы, которая просто повторяет «привет» и больше ничего не делает, а также время проверки связи с трех серверов AWS. Ясно, что временами там можно увидеть большие шипы.

Вы можете просто поспорить, но это нетворкинг! Конечно, у вас могут быть сбои из-за того, что AWS разговаривает с этим сервером в течение дня. Достаточно верно, но вот пинг в течение ТОЧНОГО того же периода времени от ТОЧНЫХ тех же серверов AWS к статической странице в Apache, измеренный на этот раз в миллисекундах (меньше, чем PHP, который должен обслуживать даже простую страницу):

Как видите, это тоже не внешняя сеть, потому что пинг статического файла никогда не был медленным. Вообще никаких проблем. Фактически мы настроили этот статический пинг файла для работы со вторым экземпляром Apache в этом ящике, чтобы убедиться, что он имеет нулевую нагрузку для получения базовых показателей. В конце пинга вы можете увидеть, что все начало немного сходить с ума, а время пинга постоянно меняется. Это потому, что мы только что включили PHP в этом экземпляре и обслужили тот же файл hello.php из этого второго экземпляра apache, чтобы увидеть, что он изменит. В первую очередь потому, что первый экземпляр также обслуживает реальный живой трафик для наших блогов wordpress и рекламных серверов (трафик небольшой, но не нулевой). Итак, очевидно, что как только мы добавляем что-то, что требует гораздо большего количества ЦП, все начинает шататься.

Итак, мой вопрос: сталкивался ли кто-нибудь еще раньше с подобными проблемами с KVM, и если да, то как их решить? Мы находимся на грани отказа от этого решения KVM и перехода либо обратно на выделенные машины (от чего мы отказались десять лет назад), перехода на частное облако VMware или рассмотрения перехода на Google или Azure (оба варианта будут стоить нам намного дороже. Деньги). Но я не вижу смысла переходить на другую облачную архитектуру, такую ​​как Google, Azure или частное облако VMware, если у них могут быть похожие проблемы?

Какие-либо предложения?