Шедулер что это такое
Планировщик заданий в ОС Windows 10
Содержание
Общая информация
Планировщик заданий — это оснастка mmc (Microsoft Management Console), с помощью которой можно назначить различные задания, которые будут производиться в определенное время или при возникновении определенных событий. Как правило, такие задания применяются для автоматизации отдельных процессов:
Операционная система Windows 10 содержит несколько инструментов для планирования заданий, включая такие, как Планировщик заданий, инструмент командной строки Schtasks и несколько командлетов консоли Windows PowerShell. Эти инструменты можно использовать для планирования заданий как на локальных, так и на удаленных рабочих станциях.
Задания могут иметь разные связанные с ними свойства, включая следующие:
Запуск планировщика заданий
1 способ
Рис.1 Запуск планировщика заданий
По умолчанию консоль подключена к локальному компьютеру. Для работы с заданиями удаленных компьютеров в оснастке Управление компьютером можно щелкнуть ПКМ по корневому узлу Управление компьютером в дереве консоли (левая панель) и в контекстном меню выбрать команду Подключиться к другому компьютеру. В открывшемся диалоговом окне Выбор компьютера установить радиокнопку Другим компьютером и ввести имя требуемого компьютера в соответствующее поле, после чего нажать кнопку OK).
Рис.2 Планировщик заданий
2 способ
3 способ
Рис.3 Запуск планировщика заданий
4 способ
5 способ
Пользовательский интерфейс Планировщика заданий
Панель слева содержит узел Библиотека планировщика заданий, который находится по умолчанию под узлом Планировщик заданий. Узел Библиотека планировщика заданий содержит задачи в виде иерархии узлов. Узел Microsoft, расположенный под узлом Библиотека планировщика заданий, содержит узел Windows, в котором находятся все системные задачи, используемые компонентами операционной системы.
Панель в центре экрана показывает имя и информацию о выбранной задаче. В нижней части центральной панели доступна панель просмотра, в которой показаны подробности по выделенной задаче.
На панели Действия доступны основные действия для выделенной задачи или узла. Новые задачи можно создавать при помощи действия Создать простую задачу, предназначенного для простых задач, или при помощи действия Создать задачу, предназначенного для задач, обладающих расширенным набором функций.
Рис.4 Просмотр и управление запланированными заданиями
Для работы с заданием можно щелкнуть по нему правой кнопкой мыши в основной панели и в контекстном меню выбрать одну из следующих команд:
Чтобы увидеть выполняемые задачи, необходимо щелкнуть ПКМ по узлу Планировщик заданий и в контекстном меню выбрать команду Отображать все выполняемые задачи.
Рис.5 Настройка отображения выполняемых задач
Основные действия в планировщике заданий
Рис.6 Основные действия в Планировщике заданий
Создание планируемых заданий (создание простой задачи)
Рис.7 Создание простой задачи
В данной статье будет приведен пример создания простой задачи, которая бы напоминала пользователю при входе в операционную систему MS Windows 10 о каком-либо событии, например, посещении сайта COMSS.
Рис.8 Создание простой задачи
Рис.9 Создание простой задачи
Рис.10 Создание простой задачи
Рис.11 Создание простой задачи
Рис.12 Создание простой задачи
Рис.13 Результат запланированной задачи
Создание похожей задачи, которая бы была направлена на открытие определенной страницы в каком-либо установленном браузере при входе в операционную систему MS Windows 10
Рис.14 Создание простой задачи
Рис.15 Результат выполненной задачи
Создание планируемых заданий (создание задачи без использования мастера)
Для рассмотрения механизма создание задачи без использования мастера, в статье будет описан пример задачи, с помощью которой ежедневно в 23.00 компьютер в автоматическом режиме завершал бы работу.
Если задание должно выполняться под иной учетной записи, чем учетная запись текущего пользователя, можно нажать кнопку Изменить. В открывшемся диалоговом окне Выбор: «Пользователь» или «Группа» выбрать пользователя или группу, с чьей учетной записью нужно выполнять задание, а затем предоставить необходимые учетные данные.
Рис.16 Создание задачи
Рис.17 Создание задачи
В данном примере, если необходимо ежедневно завершать работу компьютера в 23.00 в окне Создание триггера:
Рис.18 Создание задачи
В данном примере необходимо указать путь к программе shutdown с добавлением параметра /s.
Встроенная утилита shutdown позволяет удаленно или локально выключать, перезагружать систему, а также осуществлять вывод пользователя из текущего сеанса. Параметр /s позволяет осуществить завершение работы компьютера. Утилита shutdown расположена в следующей директории: C:\Windows\System32
Рис.19 Директория, где расположена утилита shutdown
Рис.20 Создание задачи
При наступлении времени завершения работы, указанного в настройках задачи, компьютер будет выключен.
Рис.21 Результат выполнения задачи
Просмотр ранее созданных задач в Планировщике заданий
Чтобы просмотреть ранее созданные задачи необходимо открыть Планировщик заданий и выбрать узел Библиотека планировщика заданий.
Scheduling: мифы и реальность. Опыт Яндекса
В последние пару лет я занимаюсь построением различных планировщиков, и мне пришло в голову поделиться своим нелёгким опытом с коллегами. Речь идёт о двух категориях коллег. Первые — это желающие узнать, как разработать свой scheduler за 21 день. Вторые — те, кому нужен новый scheduler совсем без смс и регистрации, просто чтобы работал. Особенно хотелось бы помочь второй категории людей.
Сначала, как водится, стоит сказать несколько общих слов. Что такое scheduler (планировщик, или, для простоты, «шедулер»)? Это такая компонента системы, которая занимается распределением ресурса или ресурсов системы по потребителям. Разделение ресурса может происходить в двух измерениях: в пространстве и времени. Планировщики чаще всего фокусируются на втором измерении. Обычно под ресурсом подразумевают процессор, диск, память и сеть. Но, что греха таить, шедулить можно и любую виртуальную ерунду. Конец общих слов.
Вместе со словом «планировщик» часто мелькают другие слова, вызывающие куда больший интерес публики: изоляция, честность, гарантии, задержки, дедлайны. Встречаются и некоторые словосочетания: quality of service (QoS), real time, temporal protection. Люди, как показывает практика, часто ждут от планировщиков магических сочетаний свойств, которые не могут быть достигнуты одновременно — с шедулером или без него. Если же нужные свойства достигаются, то обычно планировщики всё равно остаются непредсказуемой вещью в себе и во время их эксплуатации список вопросов только увеличивается. Я попытаюсь приоткрыть завесу тайны их поведения. Но обо всем по порядку.
Миф №1. Что тут сложного?
Чтобы объяснить и предсказать поведение систем, где есть шедулер, люди написали очень много книг, а также разработали целую теорию — и даже не одну. Как минимум стоит упомянуть scheduling theory (теорию расписаний) и queueing theory (неожиданно: в русском варианте это теория массового обслуживания). Все подобные теории довольно сложные и, если честно, просто необозримые. Одних формулировок задач планирования существует целый зоопарк со специальной классификацией. Дело не облегчается тем, что про бóльшую часть задач известно, что они NP-полные или NP-трудные. Даже в удачных случаях, когда есть полиномиальный алгоритм поиска оптимального решения или его неплохое приближение, частенько выясняется: для онлайн-версии задачи (когда заранее неизвестно, какие запросы нужно шедулить или когда они появятся) оптимального алгоритма вообще не существует и надо быть оракулом, чтобы отшедулить всё «как надо». Тем не менее, дела обстоят не так плохо, как может показаться. Человечество уже очень много знает о шедулерах, а некоторые из них даже работают.
Миф №2. Шедулеры решают все проблемы
Отличная иллюстрация непредсказуемого поведения системы с шедулером — сегодняшний интернет. Это система с множеством шедулеров и абсолютным отсутствием гарантий по полосе и задержке, отсутствием изоляции и подобием справедливости в формате протокола TCP — который, кстати, даже сейчас, спустя десятилетия, изучают и улучшают, и такие улучшения могут давать значимые результаты.
Вспомним TCP BBR от Google. Авторы неожиданно говорят, что создать TCP BBR было невозможно без последних достижений в теории управления, основа которых — нестандартная max-plus-алгебра. Вот, оказывается, куда ушло 30 с лишним лет.
Но это же всё не про шедулер, скажете вы, а про flow control. И будете абсолютно правы. Дело в том, что они очень сильно связаны. В обычных системах шедулеры ставят перед некоторым узким местом — ограниченным ресурсом. Логично: ресурс в дефиците и вроде бы его надо делить справедливо. Допустим, у вас есть такой ресурс — дорожная сеть города — и вы хотите сделать для него шедулер (условно, на выезде из гаража), чтобы уменьшить среднее время в пути. Так вот, оказывается, что среднее время в пути легко вычислить, применив теорему Литтла: оно равно отношению количества машин в системе к скорости их поступления в систему. Если уменьшить делимое, то при прежней пропускной способности время в пути падает. Получается, чтобы не было пробок, надо попросту сделать так, чтобы машин на дорогах стало меньше (ваш капитан). Шедулер с такой задачей не поможет, если нет flow control. В интернете описанную проблему называют bufferbloat.
Если бы я писал свод правил «шедулеростроения», то первое правило было бы таким: контролируй очереди, возникающие за шедулером. Самый часто встречающийся мне способ контролировать размер очереди — MaxInFlight (его продвинутая версия называется MaxInFlightBytes). С ним есть проблема: дело в том, что невозможно правильно выбрать число. Выбор любого фиксированного числа будет гарантировать вам либо неполное использование полосы (1), либо излишнюю буферизацию (2) и, как следствие, увеличение среднего latency, либо, если вам очень повезёт, таймауты и потерю полосы.
Хороший flow control должен удерживать систему в точке Кляйнрока между режимами (1) и (2), максимизируя отношение throughput/latency (см. TCP BBR).
Миф №3. Справедливость нужна для изоляции
Есть две классические области применения справедливого планирования — сеть и процессор. GPS — не система позиционирования, а идеальный шедулер, одновременно обслуживающий всех своих пользователей бесконечно малыми порциями. Такой шедулер обеспечивает справедливость max-min. Настоящие шедулеры (WFQ, DRR, SFQ, SCFQ, WF2Q) обслуживают потребителей порциями конечного размера — пакетами, если мы говорим про сеть, или квантами времени, если про процессор. Эти шедулеры разрабатывают так, чтобы их поведение было максимально приближено к идеальному и чтобы они минимизировали лаг — разницу в объёме обслуживания, полученного разными пользователями. Затем для управления выделенной полосой разработчик вводит веса пользователей и начинает говорить, будто они находятся в изолированных системах с меньшей пропускной способностью. Здесь-то и кроется обман. На самом деле изоляции нет.
Пусть у нас есть процессор, который мы хотим потенциально разделять между ста пользователями. Допустим, Витя — хороший пользователь. Он отправляет на обслуживание задачи, которые выполняются за 10 мс, и готов подождать 1 с, потому что понимает: есть еще 99 пользователей. Однако другие могут отправлять задачи, которые иногда выполняются до 1 с. Предположим, что preemption невозможен. Тогда Вите в худшем случае придётся ждать 99 с. Витя, скорее всего, захочет выйти из подобной системы.
Так неинтересно, скажете вы. Что за система такая — без preemption? Система должна уметь обижать, и будет ей счастье. Хорошо, пусть при времени выполнения запроса более 10 мс мы будем включать preemption, передавать управление следующему запросу и вообще использовать лучший из известных науке справедливых шедулеров. Увидит ли Витя ответ за 1 с, как будто он в изоляции? 10 мс (текущий запрос в обслуживании) + 99*10 мс (запросы других пользователей) + 10 мс (Витин запрос) = 1010 мс. Это максимум времени ожидания — другими словами, в такой системе дела обстоят получше.
Витя говорит — отличная система! — и отправляет запрос на 1 мс. А он опять выполняется за 1 с (в худшем случае). В идеально изолированной системе такой запрос выполнился бы за 100 мс, а здесь получилось в 10 раз хуже. Мало того, что от этой секунды никуда ни деться, так ещё и в реальной системе обязательно встретятся другие проблемы:
Миф №4. Справедливость нужна, чтобы разделить полосу в соответствии с весом
Получается, справедливость не обеспечивает настоящую изоляцию, зато хорошо делит полосу. Но не тут-то было. Справедливость в таких классических шедулерах мгновенная. Это означает, что, не прислав запрос, когда придёт ваша очередь, вы не получите ресурс, и он будет разделён между остальными желающими. По прошествии длительного промежутка времени (например, 24 часов) может оказаться, что ресурс съелся совсем не в той пропорции, в которой веса были заданы потребителям. В худшем случае потребители могут приходить в любых пропорциях только в те моменты, когда нет других потребителей. В результате веса и потреблённый ресурс могут оказаться вообще никак не связаны. Это шутка, скажете вы, — так никогда не бывает. Но пусть у нас есть распределённая система со своим шедулером на каждой машине. Запросы двух пользователей приходят на две разные машины и никогда не конкурируют за ресурс, потому что на самом деле здесь два ресурса.
Если вы хотите увидеть на графиках ровные линии для агрегированного потока, стоит использовать историческую (long-term) справедливость или квотирование. Но вначале спросите себя, зачем вам это надо.
Миф №5. Выдели мне узенький канал для приоритетного трафика
Предположим, у вас есть справедливый шедулер с весами и вы хотите выделить 0,1% полосы для какого-нибудь служебного трафика, а оставшиеся 99,9% — для остального. В итоге вы получите максимальную задержку x1000. Такой феномен называется bandwidth-latency coupling. Он является прямым следствием из предыдущего рассуждения. Максимальное время задержки обратно пропорционально ширине выделенной полосы. Значит, для приоритетного трафика нужны другие механизмы.
Миф №6. Я загрузил систему на полную и начал мерить задержку
Теорема. В любой системе, загруженной больше чем на 100%, задержка ответов не ограничена сверху никаким числом. Доказательство, я надеюсь, очевидно. Очереди будут копиться, пока что-то не лопнет. Как неправильно измерять и сравнивать временны́е характеристики систем (в том числе с шедулером), рассказывает Гил Тене (можно посмотреть или почитать). Я оставлю тут только иллюстрацию:
Миф №7. Real-time scheduler может гарантировать выполнение моих дедлайнов
Если вам больше не нужен справедливый шедулер, вам, возможно, нужен шедулер, который используется в системах реального времени. Уж там-то всё наверняка хорошо и быстро. Помимо прочего, корректность работы системы реального времени зависит от выполнения задач в заданные сроки. Однако это вовсе не значит, что всё происходит быстро. Например, сроки и задачи бывают вида «сделать и внедрить новый шедулер до начала весеннего ревью». Более того — среднее время ответа в таких системах может быть очень близким к худшему случаю.
Отличительная черта RT-систем: они заранее проверяют расписание на осуществимость. «Осуществимость» здесь означает возможность соблюдения дедлайнов всех задач, а «заранее» — это, скажем, при сборке, при конфигурации системы или при запуске в ней новой задачи. Далее, есть простой способ соблюдать все дедлайны в системе, где это принципиально возможно. Речь идёт про real-time-шедулер. Например, доказано, что алгоритмы EDF (Earliest Deadline First) являются оптимальными для одного процессора. Оптимальность означает, что если для данного набора задач существует хоть какое-то выполнимое расписание, то EDF выполнит задачи до дедлайнов.
Но есть условия, при которых стройная картина мира рушится и система перестаёт укладываться в дедлайны.
Миф №8. Систему нельзя загрузить больше чем на 100%
Для определения загрузки (load factor) в RT-системах используется простая периодическая модель следующего вида. Есть задачи, которые поступают раз в Ti мс и требуют эксклюзивного владения ресурсом в течение Ci мс в худшем случае. Тогда load factor определяется как запрошеное время ресурса на одну секунду реального времени, то есть U = C1/T1 +… + Cn/Tn. В такой простой модели всё понятно, но как подсчитать load factor, если у нас нет никаких периодов, а есть только текущие задачи и их дедлайны?
Тогда load factor определяется иначе. Текущие задачи сортируются по дедлайнам. Далее, начав с одного запроса с наименьшим дедлайном во множестве M, проходим по всем запросам и добавляем их в это множество. М на каждом шаге содержит запросы, которые должны быть полностью выполнены к определённому моменту времени t. Делим их суммарную остаточную стоимость (если вдруг мы уже частично выполнили какие-то из них) на оставшееся время t – now. Полученная величина — load factor U множества M. Чтобы получить текущий load factor, остаётся найти максимум из всех полученных U. Найденная величина, как несложно догадаться, сильно меняется во времени и легко может оказаться больше 1. Расписание невыполнимо c помощью EDF тогда и только тогда, когда load factor > 1.
Если вам важно соблюдать дедлайны, то в качестве метрики, за которой стоит следить, нужно использовать описанный load factor, а не традиционную утилизацию (долю времени, когда система находилась в занятом состоянии).
О многозадачности и планировщике задач (шедулер)
Небольшой экскурс в проблемы многозадачности и реализации планировщиков.
Такими были большинство компьютеров со времён их возникновения. В память помещалась программа и данные, которые она обрабатывала. В конце работы программы в памяти хранился результат выполнения.
Тут сразу у современного пользователя возникает вопрос: а где мышка, клавиатура и монитор? А это уже надстройки над нашим конвейером. Через прерывания контроллера переферийных устройств в стройный ряд инструкций и данных, летящих из памяти вклиниваются и аппаратные команды, которые заставляют наш конвейер прерваться и перейти к определённому адресу, где расположена программа-обработчик прерывания.
Данная команда будет выводить статистику каждую секунду 5 раз:
После выполнения программы-обработчика прерывания работа конвейера возобновляется. Так работает обработка сигналов от мышки и клавиатуры. Работа с видео-картой и монитором построена иначе, но сейчас мы не будем это рассматривать.
Как вы думаете, что произойдёт, если по какой-то причине перестанут поступать прерывания от таймера? Или таймер начнёт медленнее тикать?
Операционная система посчитает, что мир стал медленнее, или же компьютер быстрее. В предельном случае процессор будет исполнять текущую задачу, не обращая внимания на остальное.
Иллюзия многозадачности
В частности, наша система станет однозадачной. Ведь никакой многозадачности нет (особенно, если мы рассматриваем однопроцессорную систему). Однако, потребность в этом есть: на компьютере могут работать несколько пользователей одновременно, а каждый пользователь хочет запустить несколько задач.
И тут появляется планировщик
Также важно помнить, что пользователю важен отклик системы. Поэтому планировщик должен быть привязан как-то к реальному времени.
И тут есть множество проблем для планировщика. Так, к примеру, нельзя определить, когда программа дойдёт до определённого момента (идеальный момент для переключения) чисто по алгоритмическим причинам.
К слову, может быть кто-то знает альтернативные подходы к реализации вычислительных систем, не процессор-шина-память?
Пара слов о проблемах реализации многозадачности
Работа с системными ресурсами напрямую предполагает работу программы в реальном режиме процессора, а не в защищённом. Работая в GNU/Linux нам невозможно получить доступ напрямую к любому участку памяти, а также работать с регистрами процессора типа sp, ip и т.д. без изменения кода ядра и его пересборки.
Как можно было заметить, действий производится довольно много, чтобы одна программа могла работать рядом с другой. При этом очень многое держится чисто на человеческих договорённостях. И любой отход от договорённостей или ошибка в программе может привести к отказу работы всего компьютера.
Надеюсь, в общих чертах было ясно, какие действия необходимы и на сколько непросто написать даже такой примитивный планировщик?
Многозадачность и справедливость
Но это в идеальном мире. В реальности же процессы вольно или невольно стараются получить времени больше, или же отдают управление раньше (через тот же sched_yield), чем им выделено. Тем не менее, за условной “справедливостью” следить нужно.
Есть 2 основных подхода к многозадачности: кооперативный и вытесняющий. В кооперативной многозадачности процессы сами решают, когда они готовы отдать управление. В вытесняющей многозадачности планировщик ведёт подсчёт времени
исполнения процессов (с помощью таймера) и сам прерывает рабочий процесс, когда тот выходит за выделенный лимит.
Кооперативная многозадачность
К примеру, для переключения между тредами может быть использована команда ThreadSwitch. Текущая задача остаётся активной (готовой) и передаёт управление следующей готовой задаче. Хоть внутри и выполняются низкоуровневые операции, для языка программирования высокого уровня данная функциональная возможность выглядит как обычная функция.
Все помнят, что такое очередь? Как работает FIFO?
Вытесняющая многозадачность
Однако, если размер кусков, на которые мы нарезаем процессорное время мал, то из-за частых смен задач (смен контекста) можно получить потерю производительности.
За счёт прогнозируемости и отзывчивости данный подход распространился на почти все современные ОС.
Говоря о расходе времени при переключении контекста, как вы думаете, на чём же больше всего теряется время?
Смена контекста (context switch)
Само собой, при смене контекста производится много работы. Часть из неё мы уже описали выше, но особого внимания заслуживает отдельный момент, который мы ещё не обсуждали.
Кеш процессора
В следующем примере мы запустим программу в 8 потоков на 8-ми ядрах. Они будут увеличивать общий счётчик до довольно большого числа. Так как они будут параллельно обрабатывать одни и те же данные, компьютер будет постоянно синхронизировать кеши.
nice и приоритет исполнения процессов
Для примера, запустим параллельно с разными приоритетами несколько экземпляров предыдущей программы:
И посмотрим на результат выполнения:
Идут почти в порядке приоритетов.
Также есть renice для изменения приоритета процессу, группе процессов или процессам определённого пользователя.
Кванты времени
Для начала посмотрим настройки, которые можно использовать для тюнинга планировщика:
Планировщики в Linux
Уже гораздо лучше. Однако и здесь есть свои проблемы. При балансировке нагрузки между процессорам необходимо время от времени производить миграцию процессов с одного процессора на другой. Для этого приходится блокировать очередь работы одного процессора другим.
Также имелись и проблемы с честным выделением ресурсов пользователям. Если один запустит 10 процессов, а другой 1, то разделение времени будет нечестым.
Помимо планировщиков общего назначения в Linux есть и планировщик для систем реального времени. Это системы, в которых важно, чтобы время реакции системы на внешний сигнал не превышало определённого времени. К примеру, от момента определения заноса до запуска сервоприводов тормозных колодок должно пройти не более 5мс. Помимо планировщика на работу влияют и многие другие части ОС, например, буферы, обработчики прерываний и т.д. Однако, и планировщик и программы должны быть специальными для работы в реальном времени.
Планировщик ввода-вывода
Помимо ресурса процессора также немаловажен ресурс ввода / вывода. С появлением и распространением SSD дела стали лучше, чем при HDD (аж 10мс для перехода к нужному участку носителя), но всё равно это сильно медленнее, чем работа с памятью. Да и в целом ресурсами лучше зря не разбрасываться.
При работе с дисковой подсистемой используется планировщик ввода / вывода. Причём для разных устройств и задач подходят разные планировщики. Так CFQ (Completely Fair Queue) и deadline планировщики сначала будут буферизировать запросы на чтение / запись, чтобы сгруппировать запросы к устройству так, чтобы эффективнее с него считать. Например, чтобы за один оборот диска можно было прочитать сектора для разных процессов.
Посмотреть доступные для устройства планировщики можно через