Предыстория: у меня есть кластер из 3-х виртуальных машин Linux. Они используют идентичные конфигурации и балансируют нагрузку с помощью балансировщика сетевой нагрузки Google.
Недавно я заметил, что нагрузка на одну из этих машин всегда значительно выше, чем на других. Не шипованный процессор, только постоянная средняя загрузка в 2–3 раза.
Аудит серверов не выявил руткитов или вредоносных программ. Список процессов практически идентичен. Использование памяти номинальное на всех машинах. Излишней подкачки нет. Все записи на диск номинальные.
При просмотре чисел SQL кажется, что машины обрабатывают 0,1% того же трафика за последние 2 недели.
Глядя на совокупное время процессора (сверху), я вижу, что процесс mysql, а также другие длительные процессы на этом компьютере, похоже, потребляют примерно на 70% больше процессорного времени, чем на двух других машинах (все перезапущены в течение часа после друг друга 2 недели назад). Это должно было произойти в течение 3-дневного периода, поскольку именно тогда графики ЦП показывают повышенное использование этого компьютера по сравнению с другими.
Кроме того, я заметил всплеск количества подключений к этому серверу через журналы ошибок. Это произошло только один раз, но, похоже, это было примерно в то время, когда проблема с процессором началась.
Выключение сервера на несколько минут через облачную консоль, похоже, устранило проблему - на данный момент.
Моя текущая гипотеза состоит в том, что всплеск соединения произошел из-за отключения, вызванного живой миграцией, и что загрузка ЦП выше, потому что новый гипервизор настроен по-другому - скорее всего, из-за исправления для эксплойтов Intel Look forward.
Может ли кто-нибудь указать мне на журнал, в котором будут отображаться миграции серверов, чтобы я мог подтвердить или исключить часть этой гипотезы, касающуюся живой миграции?
Любые другие мысли будут оценены.
Вы можете запросить сервер метаданных с виртуальной машины, чтобы проверить, будет ли выполняться динамическая миграция, и получить предварительное уведомление (за 60 секунд до события).
Вам следует запросить maintenance-event атрибут, чтобы узнать, когда должна произойти живая миграция.
Эта страница содержит инструкции о том, как запросить этот атрибут, и образец сценария Python, который вы можете адаптировать для выполнения некоторых действий в случае миграции.