Регулирование потребления ресурсов распределением задач

Это перевод Controlling resource consumption by meting out work items. Автор: Реймонд Чен.

На PDC один человек подошёл ко мне за советом о проблеме управления ресурсами, с которой они столкнулись. Грубо говоря, их система генерировала дюжины задач, каждая из которых требовала значительных ресурсов для обработки. Для простоты изложения, пусть каждая такая задача была однопоточной операцией, которая интенсивно использовала процессор и требовала 180 Мб памяти. А целевая машина была, скажем, четырёхпроцессорной машиной с 1 Гб памяти (это была автономная система, так что других работающих программ на ней не было).

Их первая попытка реализации включала создание потока для каждой задачи и отпускание их всех в борьбе за ресурсы. Это сработало не слишком-то хорошо, потому что все задачи дрались за четыре процессора и требовали в несколько раз больше памяти, чем было доступно на машине, приводя к стрессу (thrashing) как планировщика (готовых выполняться поток больше, чем свободных CPU), так и менеджера памяти (суммарная песочница (working set) больше свободной памяти). Результат был просто ужасен.

Их второй дизайн заключался в последовательной обработке задач. Запускаем первую задачу, когда она завершится - запускаем вторую, и так далее, пока не обработаем все элементы в очереди. Это работало много лучше первого дизайна, потому что только одна задача была активна в каждый момент времени, так что она могла монополизировать и процессор и память без помех для других задач. Однако, это решение не масштабировалось - производительность программы не увеличивалась, если вы добавляли процессоры или память. Поскольку работала только одна задача одновременно, все дополнительные процессоры и память просто простаивали.

Решение подобных проблем заключается в максимизации использования наиболее ограниченного ресурса. Здесь у нас есть два ресурса: процессор и память. Поскольку каждая задача требует процессор целиком (т.к. она проводит интенсивные вычисления), то запуск больше задач, чем у нас есть процессоров, приведёт к плохой работе планировщика, так что первая оценка числа одновременно выполняющихся задач - это число процессоров (4 в нашем случае). Далее, поскольку каждая задача требует 180 Мб памяти, то вы можете запустить только 5 задач одновременно на машине с 1 Гб памяти, прежде чем у вас закончится память. Поэтому, вторая оценка по памяти будет 5 задач. Итого, мы получаем, что задачи сперва исчерпают процессоры (на 4-х элементах), а лишь потом память.

Как только вы смогли определить, сколько элементов вы можете себе позволить одновременно (4), вам остаётся только поддерживать это количество, пока очередь не опустеет. Поток вашего главного планировщика будет содержать список задач для выполнения и запускать первые четыре задачи, после чего ожидать их завершения, используя функцию WaitForMultipleObjects и передавая ей bWaitAll = False, так что он проснётся, когда завершится любая задача (это не было GUI приложением, так что им не нужно было волноваться из-за прокачки сообщений). Как только завершается любая задача, главный планировщик запускает ещё одну задачу. Таким образом, у вас всегда будет четыре активные задачи, беря максимум из доступных ресурсов.

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