Downtime Bar&Grill

После вчерашней разминочки, продолжаем про CPU и мониторинг нагрузки. Казалось бы чего уж проще, смотри на общую нагрузку и радуйся жизни. Но нет, в сложных, нагруженных системах как мы выяснили в прошлом посте, делать это примерно полностью бесполезно. Сегодня разберем неочевидные и поэтому интересные ситуации с потреблением процессорных мощностей. Самый простой пример девиации, которую сложно увидеть на мониторинге это описанный в прошлый раз случай, когда процесс упирается в производительность CPU. Мониторинг многоядерной системы показывает почти полный idle, при полной загрузке одного ядра. Никаких алертов по CPU конечно не будет. Даже народная метрика Load Average, в простонародье LA, показывающая среднее количество потоков, стоящих в очередь на выполнение, такого не покажет. Именно для этого и в консольных командах вроде htop, и в экспортерах метрик есть данные по загрузке каждого ядра. Смотреть на график из 80ти ядер, выискивая причину тормозов тот еще квест, но лучше чем ничего. Еще одна метрика, которую вы никогда не увидите на общем графике нагрузки процессора это его настройки энегропотребления и частоты. Бывает редко, но иногда на железных серверах процессор может работать на трети от заявленной частоты, просто потому, что находится в режиме экономии электроэнергии. Много сэкономить не получится, а вот скорость работы приложений может пострадать, даже если частота под нагрузкой будет расти, гуглить "cpu performance governor". Предельный случай занижения частоты - защита от перегрева. Внутренняя логика процессора понижает частоту по достижении определенной температуры, что бы процессор не согрел и если у вас нет алертов на метрики снимаемые с материнской платы, вы получите снижение производительности. Производительность в этом случае не просто просядет, но может скакать, заставляя постоянно меняться время обработки. Для средней web-based системы это плюс-минус не важно, а вот для специализированных near real-time систем разброс времени обработки может стать очень большой проблемой. И тут мы приходим в облако. Облако это такой чудесный мир, где тебе примерно ничего не гарантировано. Ваш виртуальный процессор, данные которого вы видите в выводе lscpu, отделен от реального процессора системой виртуализации и аккаунтинга. Самой показательной была демонстрация теста производительности базы данных, которую мы делали в конце четырехдневного интенсива по MySQL, когда двухядерная (!) виртуалка в течении нескольких минут без малейших сомнений держала нагрузку в 12 (двенадцать!) параллельных потоков. Потом заложенное в облачный аккаунтинг время повышенной доступности ресурса закончилось и виртуалка резко умерла под нагрузкой, да так, что пришлось ее перезапускать. Было весело. Еще веселее было, когда у одного из клиентов в реальном проде сработал алерт по метрике пятисотых ошибок. Никаких работ или релизов последние сутки не наблюдалось. Собрали звонок, позвали ответственных инженеров и начали смотреть. Выяснилось, что одна из нод бекенда перестала справляться с нагрузкой. Взяла и перестала. Мониторинг показывал увеличенную нагрузку на процессор, LA на ноде улетел в небеса. Сначала решили, что балансировщику сильно поплохело и он на эту ноду полил повышенную нагрузку. Однако эта гипотеза не подтвердилась. Из балансировки ноду выкинули и начали разбираться. Перевернули все что можно. После приблизительно часа поиска один умный человек предложил проверить фактическую производительность процессора. Достали бенчмарк, прогнали и оказалось, что производительность CPU на виртуалке внезапно стала в где-то в четыре-пять раз ниже, чем была. Саппорт посмотрел что-то у себя и сказал: "перезагрузите". После перезагрузки все восстановилось. Были ли это "шумные соседи" по гипервизору и виртуалка переехала на новый гипервизор или глюканула система аккаунтинга в облаке для нас осталось загадкой. Так и живем! Рассказывайте свои истории, делитесь этим постом с другими, скоро увидимся! @downtime_bar #SRE