История одного расследования: как steal CPU незаметно тормозил наш GitLab

Коллеги, хочу поделиться историей расследования, которое заставило меня по-новому посмотреть на мониторинг виртуализации.

После работ на инстансе GitLab начали сыпаться жалобы: пайплайны не создаются, всё работает из рук вон плохо. Нагрузка выросла, CPU постоянно загружен, но даже в «спокойные» моменты система еле дышала

Что делали:

➡️ Провели регламентные работы по оптимизации — безрезультатно
➡️ Искали проблемы в новой версии — возможно, но не очевидно
➡️ Смотрели на стандартные метрики — везде «нормально», но ничего не работает

А решение оказалось в одном показателе — steal CPU

В пиках он достигал 20%! Это был явный сигнал, что проблемы на уровне гипервизора. Проверили — да, гипервизор перегружен. После перераспределения ВМ steal CPU упал до привычных 1-2%, и система сразу ожила

Выводы:

1️⃣ Steal CPU — та метрика, которую стоит мониторить всегда
2️⃣ Иногда проблема не в вашем коде, а в инфраструктуре под ним
3️⃣ Простые решения часто эффективнее сложных оптимизаций (что не может не радовать)

Теперь все наши дашборды в Grafana включают этот показатель. А те оптимизации, что начали делать — стали приятным бонусом к производительности (об этом расскажу позднее)

Почитать подробнее про Steal CPU можно тут. А если вы тоже сталкивались с подобными кейсами — поделитесь в комментариях, обсудим ⬇️