 | Можно создавать до 8 партиций. |
Практические вопросы применения планировщика потоков
Статья включает:
Как правило, планировщик потоков используется для:
В любом случае необходимо настраивать параметры планировщика потоков в контексте всей системы. Ответьте на следующие основные вопросы:
Размещение функционально связанных между собой программ в одной партиции представляется разумным и, как правило, оптимальным решением, однако планирование с адаптивными партициями — это механизм, который блокирует выполнение программ. Следовательно, в качестве критерия группировки программ в партициях следует использовать условия, при которых они будут лишаться ресурса CPU.
| Можно создавать до 8 партиций. |
Например, если система представляет собой маршрутизатор, который:
имеет смысл создать две партиции, одна из которых обслуживает маршрутизацию, а другая — топологию. Очевидно, что регистрация метрик маршрутизации функционально связана с маршрутизацией пакетов.
Тем не менее, если устройство перегружено и не успевает выполнять всю необходимую работу, необходимо решить, какую ее часть следует отложить. Когда маршрутизатор перегружен входящими пакетами, необходимо продолжать маршрутизировать их, и если ресурсов на выполнение всех задач не хватает, следует отказаться от сбора статистики в пользу маршрутизации. Путем аналогичных рассуждений можно прийти к выводу, что необходимо продолжать работу протоколов топологии маршрутизации, которые расходуют значительно меньше времени CPU, чем собственно маршрутизация, но должны выполняться быстро.
В этом случае можно создать три партиции:
Мы группируем функционально связанные компоненты маршрутизации и регистрации метрик, поскольку хотим приостанавливать выполнение только одной из функций при нехватке ресурсов. Аналогичным образом мы группируем два функционально несвязанных между собой компонента — регистрацию метрик маршрутизации и метрик топологии, поскольку хотим приостанавливать их работу при возникновении одних и тех же условий.
Количество времени CPU, которое каждая партиция планировщика расходует при неполной нагрузке, является хорошим ориентиром при определении ее оптимального бюджета. Если приложение обрабатывает транзакции, рекомендуется измерить расход времени CPU при различных нагрузках и построить соответствующий график зависимости.
Как правило, следует определять оптимальное соотношение бюджетов партиций опытным путем:
| Партицию невозможно удалить, но можно удалить все ее процессы и назначить ей нулевой бюджет. |
Можно назначать партиции нулевой бюджет, если не установлен флаг безопасности SCHED_APS_SEC_NONZERO_BUDGETS (см. команду SCHED_APS_ADD_SECURITY функции for SchedCtl()).
Потоки партиции с нулевым бюджетом выполняются только в следующих случаях:
Когда следует назначать партиции нулевой бюджет?
Целесообразно назначать партиции нулевой бюджет в следующих случаях:
| Обычно не рекомендуется назначать партиции нулевой бюджет (поэтому параметр безопасности SCHED_APS_SEC_RECOMMENDED запрещает это действие). Основной риск размещения потока в партиции с нулевым бюджетом связан с тем, что поток может включать в себя обработку импульса или события, а не сообщения; следовательно, он не будет выполняться в партиции отправителя. В результате при полной загрузке системы (т.е. в отсутствие свободного времени) такие потоки могут не запускаться или запускаться в неправильном порядке.
Например, назначение нулевого бюджета партиции System на полностью загруженном устройстве создает риск «зависания» запросов создания процессов и потоков к модулю procnto-* при использовании флага |
В идеальном варианте менеджеры ресурсов (например, файловые системы) должны всегда работать с нулевым бюджетом и зачислять расходуемое время CPU на счет своих клиентов. Тем не менее, некоторые драйверы устройств не успевают своевременно определять, какого клиента обслужил тот или иной поток. В некоторых драйверах проверки и вспомогательные действия могут выполняться фоновыми потоками, расход CPU которых невозможно отнести к конкретному клиенту. В таких случаях следует измерять фоновые и не связанные с клиентами нагрузки менеджера ресурса и зачислять их в бюджет его партиции.
|
|
Размер окна усреднения можно задавать в диапазоне от 8 до 400 миллисекунд. Окно усреднения — это временной интервал, в котором планировщик потоков балансирует партиции таким образом, что каждая из них получает гарантированное время CPU. Длительность окна усреднения влияет на точность балансировки нагрузки, а в экстремальных случаях — на максимальные задержки готовых к выполнению потоков.
Следует иметь в виду, что:
+/- (длительность_такта / размер_окна_усреднения). Например, если размер окна усреднения равен 10 миллисекундам, точность составляет около 10%.
При небольшом размере окна усреднения это время может быть нулевым. Если длительность бездействия партиции превышает размер окна усреднения, ее время не компенсируется. Таким образом, балансировка нагрузки выполняется с низкой точностью в долгосрочном периоде при полной загрузке системы и бездействии партиций в течение времени, превышающего размер окна усреднения.
Планировщик не задерживает готовые к выполнению потоки при неполной нагрузке, однако не всегда передает управление потоку с максимальным приоритетом при балансировке бюджетов.
В крайне маловероятных случаях возможны задержки выполнения некоторых партиций при большом размере окна усреднения, однако длительность этих задержек всегда меньше, чем при планировании без применения адаптивного партиционирования. Указанные задержки могут возникать в двух ситуациях.
Ситуация 1
Если обозначить размер бюджета партиции планировщика в миллисекундах как бюджет, максимальная задержка составляет:
размер_окна_усреднения − минимальный_бюджет + максимальный_бюджет
Максимальная задержка возникает только в случае, если партиции с маленьким бюджетом и низким приоритетом взаимодействуют с двумя другими партициями определенным образом и все потоки в системе очень долго находятся в состоянии готовности к выполнению. Вероятность возникновения максимальной задержки крайне невелика.
Для примера рассмотрим следующие партиции планировщика:
Максимальная задержка возникает в следующей ситуации:
| Описанная ситуация может возникать лишь при условии, что высокоприоритетная партиция активизируется ровно в тот момент, когда низкоприоритетная партиция завершает возмещение сверхурочно использованного времени. |
Ситуация 2
Редкая, хотя и более вероятная задержка длительностью:
размер_окна − бюджет
возникает при выполнении партиций, которые имеют небольшой бюджет и такие же средние приоритеты, как у других партиций.
Если партиция состоит из множества потоков с типичным набором приоритетов, максимальная задержка ее выполнения, как правило, значительно меньше размера окна усреднения.
Допустим, у нас есть три партиции планировщика:
Указанная задержка возникает в следующей ситуации:
Описанный алгоритм реализуется только при условии, что приложение с бюджетом 10% никогда не приостанавливается и при этом отсутствуют потоки с другими приоритетами (и то, и другое крайне маловероятно).
Приблизительная оценка задержек
Поскольку описанные ситуации нетривиальны и максимальная задержка готовых к выполнению потоков зависит от бюджетов партиций, мы считаем ее приблизительно равной двукратному размеру окна усреднения.
| Изменять длительность такта системных часов в процессе работы системы следует до задания размера окна усреднения планировщика потоков, поскольку ЗОСРВ «Нейтрино» преобразует размер окна усреднения из миллисекунд в такты для внутреннего использования. |
Для практической проверки корректности задержек планирования можно применять к системе стрессовые нагрузки и наблюдать задержки в системном профилировщике интегрированной среды разработки. Команда aps coпозволяет назначать партициям необходимые бюджеты во время работы системы.
Минимальный размер окна усреднения, который можно задавать с помощью API, равен 8 миллисекундам, однако на практике используются большие значения. Например, если в системе имеется 8 активных партиций, то для того, чтобы они выполнялись в каждом окне усреднения, его размер должен составлять не менее 8 тактов (32 миллисекунд в большинстве систем).
Существует несколько ситуаций, в которых партиция планировщика лишает другие приложения доступа к гарантированному бюджету времени CPU:
Время, которое расходуется потоками обработки прерываний (например, потоками, в которых используется функция InterruptAttachEvent()), корректно зачисляется на счет соответствующих партиций.
Предыдущий раздел: перейти