История одного расследования: как steal CPU незаметно тормозил наш GitLab
Коллеги, хочу поделиться историей расследования, которое заставило меня по-новому посмотреть на мониторинг виртуализации.
После работ на инстансе GitLab начали сыпаться жалобы: пайплайны не создаются, всё работает из рук вон плохо. Нагрузка выросла, CPU постоянно загружен, но даже в «спокойные» моменты система еле дышала
Что делали:
➡️ Провели регламентные работы по оптимизации — безрезультатно
➡️ Искали проблемы в новой версии — возможно, но не очевидно
➡️ Смотрели на стандартные метрики — везде «нормально», но ничего не работает
А решение оказалось в одном показателе — steal CPU
В пиках он достигал 20%! Это был явный сигнал, что проблемы на уровне гипервизора. Проверили — да, гипервизор перегружен. После перераспределения ВМ steal CPU упал до привычных 1-2%, и система сразу ожила
Выводы:
1️⃣ Steal CPU — та метрика, которую стоит мониторить всегда
2️⃣ Иногда проблема не в вашем коде, а в инфраструктуре под ним
3️⃣ Простые решения часто эффективнее сложных оптимизаций (что не может не радовать)
Теперь все наши дашборды в Grafana включают этот показатель. А те оптимизации, что начали делать — стали приятным бонусом к производительности (об этом расскажу позднее)
Почитать подробнее про Steal CPU можно тут. А если вы тоже сталкивались с подобными кейсами — поделитесь в комментариях, обсудим ⬇️
Post #1021
1.76K