Throttling - бесполезная трата CPU

К такому выводу я пришёл на одном из проектов. Если контейнер приложения находится в состоянии тротлинга, это может вызвать не только замедление вычислений, но и бессмысленный перерасход CPU. Суммарно перерасход может достигать 50%, т.е. до половины выделенных процессорных ресурсов может уходить на “обогрев воздуха”, а не на полезную работу.

Всё началось с того, что нужно было достаточно точно измерить время использования CPU (CPU Usage) параллельно выполняющихся процессов ОС. Точность измерения оценивалась относительно аналогичного показателя, полученного при последовательном выполнении. По итогу нужно было выполнить калибровку системы и найти оптимальный уровень параллелизма, при котором CPU Usage каждого процесса приемлемо близок к эталону.

Иначе говоря, представьте, что есть некоторая вычислительная программа (задача, функция). Сначала делается серия последовательных запусков программы, и для каждого процесса измеряется его CPU Usage. Затем делается серия параллельных запусков с разным уровнем параллелизма. Например, в первой серии запускается по 2 одновременно работающих процесса; во второй – по 4, в третьей – по 8 и т.д. Все процессы запускаются в одном и том же окружении и выполняют одну и ту же вычислительную работу. По условию задачи уровень параллелизма считается приемлемым, если CPU Usage параллельного исполнения не превышает 30% последовательного.

Для чего всё это нужно? Если у вас есть большой объём/поток вычислительных задач, и нужно обработать его как можно быстрей, но так, чтобы вычислительные затраты на каждую задачу были минимальны. Минимальны, значит, основная работа должна идти на вычисления, а не на переключение контекста и прочие накладные расходы, связанные с организацией параллелизма.

Конкретно в моём случае требовалось сделать проверку олимпиадных решений по программированию. Сделать это нужно было как можно скорей, а CPU Usage при этом использовался как критерий оценки корректности решения.

Проведя серию экспериментов, я ожидаемо подтвердил закон Амдала, но самое интересное заключалось в другом. С ростом уровня параллелизма CPU Usage начинает значительно деградировать – в среднем до 50% относительно эталона.

Положительный момент в том, что деградация не бесконечна и имеет предел; отрицательный – большая часть вычислительных ресурсов тратится на организацию параллелизма. Выводы очевидны, но полученные мной показатели заставили относиться к вопросу более серьёзно.

Интересно и то, что ОС включает затраты на переключение контекста в статистику процесса. Это справедливо, но немного неожиданно, ведь за переключение контекста отвечает диспетчер задач ОС, а не процесс.

Какие из этого можно сделать выводы?

Частый тротлинг – проблема в конфигурации лимитов или неадекватно большом уровне параллелизма. В Kubernetes для контроля тротлинга можно использовать метрику container_cpu_cfs_throttled_seconds_total.
Тротлинг – это момент, когда потоки ОС часто и много конкурируют за CPU, следовательно, значительная часть вычислительных ресурсов используется впустую. Это справедливо, ведь большая часть приложений – это многопоточные web-приложения.
Превалирование принудительных переключений – это CPU-bound-задачи или высокий уровень параллелизма. Для большинства приложений справедливо второе. Подтвердить данный факт можно, посмотрев на соотношение метрик voluntary_ctxt_switches и nonvoluntary_ctxt_switches (добровольные и принудительные переключения), которые доступны в файле статуса Linux-процесса /proc/<PID>/status.
CPU Usage – это не абсолют, это плавающий показатель. Анализируя или сравнивая профили производительности приложения, смотрите не только на CPU Usage, но и на Elapsed Time, также принимая во внимание количество параллельных вычислений, производимых во время снятия профиля.

А какие подходы позволяют контролировать уровень параллелизма, рассмотрим в следующий раз. Всем добра и поменьше параллельных активностей!

Понравилась статья?