Пока готовился к докладу, окунулся в метрики мониторинга CPU. В получасовой доклад всю эту радость впихивать совершенно бесполезно, поэтому поговорим об этом здесь.

Самая частая метрика нагрузки CPU, которую можно увидеть во многих, если не всех системах мониторинга, это общая нагрузка на CPU, она же Overall CPU Utilization. Считается она очень просто: время нагруженной работы всех ядер в единицу времени (секунду) складывается, потом делится на общее время всех ядер и показывается в процентах.

Казалось бы, что еще нужно? Проблема в том, что такая метрика хороша на одноядерной системе: 80% нагрузки означает, что 20% времени свободно и на него никто не претендует. В многопоточных системах это не значит примерно ничего. В 48ми ядерной системе может работать 40 процессов, выжирающих свои ядра CPU в ноль, и overall load будет показывать 83-85% при занятых ядрах. Такая ситуация например бывает, когда количество одновременных потоков по ошибке выставили меньше количества ядер, например в nginx или в БД.

Поэтому при анализе нагрузки стараюсь смотреть на другие метрики, первая из которых - количество используемых ядер. 100% используемых ядер означает, что нагрузка успешно распределяется и система эффективно утилизирует железо. Если при этом общая метрика времени CPU time на виртуалке или сервере меньше 60-70% (по большей части эмпирическая величина, но математика за этими цифрами тоже есть), система работает в оптимальном режиме с двумя замечаниями.

Замечание первое: смотреть нагрузку нужно в пиковое время. Обзор нагрузки, в момент когда она далека от максимальной, это как читать рекламные объявления о продаже квартир в новом ЖК: "15 минут до центра". И не врут ведь, действительно 15. Только выезжать нужно часа в 4 утра, потому что, когда все едут на работу, быстрее чем за час на машине не доехать.

Замечание второе: нет ли на боксе в это время процессов или потоков, упирающихся в CPU и жрущих одно ядро полностью и на долго. Большое количество вычислений, выполняющихся довольно долго на одном ядре это вариант нормы для определенных типов нагрузки, но требующий анализа и ответа на сколько вопросов. Не нужно ли разбить задачу на несколько ядер? Нет ли возможности оптимизировать логику работы? Не вынести ли этот функционал на отдельную машину, что бы не мешал остальным процессам? Эксплуатация нагруженных и не очень систем требует внимания к таким деталям.

Что еще важно в мониторинге CPU? Это безусловно распределение типов нагрузки на процессор. Большую часть времени CPU должно обслуживать пользовательские программы, это время так и называется: user time. Другие метрики несут названия соответствующие задачам

system/cs: время проведенное в ядре и потраченное на переключение (context switches). Время проведенное в обработке прерываний (irq,softirq) может показываться отдельно. Это время, которое операционная система использует для переключения (scheduling) процессов между ожиданием и выполнением или между разными ядрами.

io/iowait/wa: время проведенное в ожидании ввода-вывода. По факту это время, когда процесс, занявший процессов, ждет ответа ядра операционной системы. Самый простой пример: мы пишем файл и хотим убедиться, что данные фактически доставлены на диск. Вызывав в коде fsync, мы заставляем ядро выполнить сброс буферов дескрипторов файла и кеша, что занимает существенное время даже на SSD дисках. CPU в это время ждет окончания работы вызова, тратя время на предиктивное выполнение или предоставляя ресурсы ядра другому процессу, например через Hyper Threading.

В общем случае, высокие значения system time и iowait говорят девиациях в нагрузке и требуют внимания.

tldr; общая метрика нагрузки CPU является средней температурой по больнице и может скрывать проблемы производительности. Если хотите сделать систему быстрее или дешевле, смотрите на нагрузку по ядрам, внимательно смотрите за system time и iowait, можете узнать много интересного!

Пишите, про ваш опыт мониторинга производительности, делитесь своими историями, до следующей встречи!

#SRE @downtime_bar: Осенние лекции | Интенсивы