Шедулер что это такое
990x.top
Простой компьютерный блог для души)
Task Scheduler — что это за программа и нужна ли она?
Планировщик задач Windows, где находятся запланированные задания — системные и сторонних программ.
В планировщике могут быть и опасные задания, которые маскируются под известные программы. Простыми словами — вирусы.
Как открыть планировщик задач? Например просто напишите планировщик задач в поиске на панели задач (внизу) и в результатах найдете нужное.
Но мне кажется, что лучше всего запускать Task Scheduler (планировщик задач) при помощи команды. Это просто универсально, работает на Windows 7, Windows 10 и наверно даже в Windows XP.
Итак, зажмите Win + R, появится окошко Выполнить, вставьте команду:
Нажали ОК — запустится планировщик задач:
Слева как видите есть разделы, их там много, но обычно интерес представляет раздел Библиотека планировщика заданий (Task Scheduler Library):
В этом разделе идут задания разного софта, иногда есть подозрительные, как я уже писал они могут быть от вирусов. Например у меня здесь задания такие:
Это только пример. Их может быть много, намного больше. Если Windows только установлена, то их будет минимальное количество.
Что такое задание? Это некая запись, в которой прописаны условия запуска программы или ее компонента — что и когда. Запланировано может быть например каждый день, раз в неделю, раз в месяц, или вообще одноразово, при входе пользователя в систему и так далее. Задания обычно вручную не добавляются, программы сами их добавляют, часто при их установке.
Давайте возьмем одно задание и разберем его для примера, пусть это будет Anvirlauncher. Чтобы вызвать свойства — нажмите по нему два раза мышкой, после чего появится окно с информацией:
Здесь мы сразу видим — от какого пользователя выполняется задание, с какими правами, еще может быть описание задание, но его отсутствие — не редкость.
На вкладке Триггеры указано когда именно запускается задание:
Важная информация находится и на вкладке Действия — что именно запускается, какой процесс и из какой папки:
Таким образом вы сможете кстати понять что за программа запускает, часто папка запуска процесса содержит название ПО.
На остальных вкладках уже информация не особо интересна.
Кстати вот например взять задание OneDrive Standalone Update Task, у него на вкладке Триггеры указано что запускается только один раз:
Правда здесь какой-то глюк, дата и время указано странно — 14:00 01.05.1992, но возможно это специально так, чтобы задание выполнилось один раз и неважно какая дата сейчас, главнее не раньше, чем 01.05.1992, что в принципе быть невозможно. Поэтому задание запустится один раз в любом случае. И кстати такие задания, где запуск один раз и дата уже прошла — можно удалить, они просто не нужны.
Чтобы удалить задание, отключить, выполнить или посмотреть его свойства — достаточно просто нажать по нему правой кнопкой и выбрать нужный пункт:
На этом все, надеюсь информация была полезной, вы узнали что такое Task Scheduler, что это планировщик заданий, в котором находятся системные задания от Windows, а также от стороннего софта.
Что такое планировщик встреч и чем он может быть полезен для вашего бизнеса
Расскажем на конкретных примерах.
Привет, меня зовут Владимир, и я ненавижу заниматься планированием. Вместо того чтобы тратить время на действительно важные дела, мне приходится назначать встречи, неделями переписываться, чтобы определиться с датой конференц-звонка, и терять деньги из-за того, что кто-то забыл добавить в календарь важное событие.
И я такой не один. Только у меня наберется с десяток знакомых с аналогичной болью на душе, не говоря уже о том, какой сегмент бизнеса в РФ безуспешно пытается избавиться от тех же проблем и продолжает страдать.
Почему мы вообще страдаем? Все дело в средствах планирования, которыми мы располагаем. Классические календари и переписки по электронной почте устарели, и их давно пора заменить на планировщики встреч, которые уже какое-то время работают на западе, но все никак не дойдут до РФ.
Но у меня и моей команды Makemeet есть предложение на этот счет.
Планировщик встреч (шедулер) — это автоматизированный секретарь, который берет на себя обязанности по планированию бизнес-встреч, конференц-звонков и других мероприятий. Вы сообщаете программе, в какое время свободны и готовы провести встречу, а шедулер «общается» за вас с другими людьми, оповещает их об актуальном расписании и создает события в календаре.
Наиболее понятный пример, с которым каждый из вас наверняка хотя бы раз сталкивался, — запись к доктору через госуслуги или сайт клиники. Вы не связываетесь с доктором напрямую, не обсуждаете время встречи, а просто выбираете свободную ячейку времени в его расписании и автоматически оказываетесь в списке записанных пациентов. Но такое доступно только в дорогущих CRM после длительной и сложной настройки.
А шедулер — решение для всех, в котором каждый может создать собственное расписание без всяких CRM. Достаточно сообщить приложению, в какое время вы готовы планировать встречи. После этого программа создаст интерфейс, через который к вам «на прием» смогут записаться все пользователи, со ссылкой на ваше расписание.
Но хороший шедулер — это не только инструмент для планирования, а еще и инструмент, который легко встраивается в уже давно устаканившийся рабочий процесс за счет интеграции с популярными сервисами и приложениями. К примеру, интеграции с Zoom, позволяющей после каждой записи автоматически генерировать уникальную ссылку для выхода на связь (не придется оставлять контакты, вручную создавать ссылку и прикреплять ее к событию в календаре). Или интеграции со Stripe на тот случай, если ваш бизнес оказывает услуги по предоплате.
Все они выполняют одну и ту же задачу, но отличаются интегрируемыми сервисами, некоторыми параметрами для календарей, а также поддерживаемыми языками и стоимостью предоставляемых услуг.
Calendly — один из наиболее популярных, и с ним чуть ли не ассоциируется такое явление, как шедулеры. У Calendly интуитивно понятный интерфейс с симпатичным оформлением, в которое можно без труда вписать собственный логотип, корпоративные цвета и т.п.
В Calendly есть весь базовый набор опций, типичных для шедулеров: ограничение количества свободных временных ячеек, оповещения о новых записях по почте и push-уведомления. Но самое главное — огромное количество интеграций со сторонними службами и программами, включая Teams, Zoom, iCloud, Google Calendar, Slack, PayPal и другие.
Далее будем рассматривать шедулеры на примере Calendly, так как это наиболее конкурентоспособный продукт в своей категории.
За рубежом уже есть удачные примеры применения шедулеров на практике, когда выручка бизнеса заметно возрастала благодаря новому подходу к формированию расписания.
Популярный в США мебельный бренд La-Z-Boy из-за коронавирусных ограничений был вынужден закрыть магазины и искать способ взаимодействия с клиентами удаленно. Выходом стали индивидуальные онлайн-экскурсии для клиентов с гидом-дизайнером, который мог бы показать товар, рассказать о нем, подобрать сопутствующую мебель и аксессуары.
Услуга стала на удивления популярной, и La-Z-Boy столкнулся с неожиданно большим потоком пользователей. Они задействовали Calendly и создали в программе 60 ячеек для 60 потенциальных гостей соответственно. Благодаря возможностям, простоте и эффективности приложения магазин за 2 месяца увеличил эту цифру до 410 «слотов».
В России виртуальные экскурсии проводят в сфере недвижимости при продаже и сдаче квартир в аренду. Торговая площадка Авито дает подобную возможность, правда, на совсем базовом уровне, предлагая пользователям самим выяснить время встречи и программу для общения.
Используя планировщик встреч, риэлторы могли бы автоматизировать создание встреч в своем рабочем календаре (как онлайн, так и вживую), просто оставив ссылку на свое расписание со свободными ячейками на Авито или любой другой площадке.
Даже если интерфейс Авито или любой другой площадки не предлагает возможности оставить ссылку на Calendly или его аналог, можно отправить ее через СМС или мессенджеры в духе WhatsApp.
Также в ссылку шедулера можно интегрировать Zoom и Teams для конференц-звонков. Потенциальному клиенту достаточно будет указать нужный способ связи в шедулере, и для вас двоих автоматически будет создана ссылка для общения в назначенную дату.
У сервиса по составлению генеалогического древа Ancestry была ситуация, похожая на ту, с которой столкнулся бренд La-Z-Boy. В какой-то момент приток пользователей, желающих воспользоваться сервисом, вырос настолько, что сотрудники, общающиеся с клиентами, перестали успевать обрабатывать все заявки.
С появлением Calendly этап общения менеджера и клиента почти выпал из рабочего процесса Ancestry. Все желающие воспользоваться услугами сервиса сами записывались через интерфейс Calendly – люди выбирали удобное для себя время и в пару кликов «записывались на встречу» с сотрудниками Ancestry без участия менеджеров.
Аналогичный инструмент могли бы применять российские компании, демонстрирующие свои продукты и сервисы только по предварительной записи. Процесс оформления заявки на демо какой-нибудь CRM всегда сопровождается бюрократией и ненужным общением с менеджерами по продажам, которые допускают ошибки, не выходят на связь и усложняют весь процесс работы. Люди могут часами и днями не отвечать на сообщения, что затягивает весь процесс и сокращает общее количество заявок на единицу времени.
Планировщик встреч бы исключил этот отнимающий впустую время этап взаимодействия с клиентом.
Многие предприниматели интересовались тем, как работает бизнес-планировщик Signpost, и хотели посмотреть, как он проявляет себя в рабочей среде, но зачастую не могли этого сделать из-за всякой волокиты в духе долгой переписки по почте.
Сотрудники Signpost знали, что теряют деньги. Слишком много «горячих» лидов превращались в «холодные» на глазах у «эффективных» менеджеров компании.
Принципиальные изменения произошли сразу после того, как менеджеры компании взяли на вооружение Calendly. Они настроили автоматическую отправку ссылки на интерфейс планировщика первым же письмом для каждого потенциального клиента. То есть каждый, кто заказывал демо Singpost, тут же получал доступ к расписанию менеджеров компании и мог выбрать для себя наиболее удобное время демонстрации. Без звонков и длительных переписок.
Подобную стратегию можно использовать в отделе кадров, чтобы не тратить время на обзвон потенциальных наемников и не терять драгоценные часы на ненужных телефонных разговорах о том, когда же будет удобно провести собеседование.
Вместо того чтобы списываться с кандидатом на должность, ждать от него заполнения анкет и предоставления прочих данных, можно отправлять ему по почте или через СМС ссылку на интерфейс планировщика, где соискатель сам выберет время, когда ему будет удобно пообщаться с HR’ом.
HR’у не придется за ручку водить каждого кандидата и обсуждать детали грядущего интервью. Можно прямо в шедулере указать и средство связи, и всю информацию, которая понадобится потенциальному сотруднику в ходе собеседования.
Директор известного сервиса по сокращению ссылок Bitly решил внедрить Calendly после того, как понял, что для первичного выхода на связь с потенциальным клиентом сотрудникам компании все еще приходится звонить по телефону. Такой метод взаимодействия не нравился начальству, не нравился менеджерам и не нравился клиентам. Зависимость от часового пояса, пропущенные вызовы и другие неприятные особенности планирования по телефону выливались для Bitly в потерянную прибыль.
Сначала руководство заставило менеджеров перейти на общение по электронной почте вместо телефона, а затем внедрила Calendly как основной способ бронирования встреч для потенциальных клиентов.
После этого у Bitly на 100% выросло количество демонстраций продуктов, на 40% увеличились продажи и почти 90% всех встреч в компании стали планироваться с помощью Calendly.
В российском сегменте тоже есть проекты, демонстрация которых протекает в ходе полноценной онлайн-консультации, но реализовано это по старинке. К примеру, чтобы забронировать демо у компании GFI нужно заполнить кучу форм, оставить номер телефона и ждать, пока на связь выйдет кто-то из сотрудников фирмы. Сервис в духе Calendly исправил бы эту ситуацию и сделал жизнь проще как менеджерам GFI, так и их потенциальным клиентам.
При этом не придется лишать себя дополнительной информации о потенциальном клиенте. В планировщик встреч можно добавить собственные формы, чтобы пользователь предоставил нужные данные. Это может быть имя, адрес электронной почты или кастомное поле с персональными предпочтениями по грядущему демо.
Сотрудники дизайнерской школы College for Creative Studies в Детройте на регулярной основе должны участвовать в различных мероприятиях, разъезжать по встречам, опрашивать бывших студентов и параллельно преподавать. При таком жестком графике планирование по телефону или электронной почте превращается во внушительного пожирателя времени, отнимающего несколько часов у и без того загруженного дня.
Одна из сотрудниц College for Creative Studies опробовала шедулеры. Первым был сервис Meetingbird, который справлялся с поставленной задачей, но не мог предложить дополнительные инструменты для автоматизации процесса назначения встреч.
С переходом на Calendly ситуация стала еще лучше, потому что специалисты College for Creative Studies перестали тратить время на поиски удобного расписания, начали встречаться с большим количество людей и опрашивать больше студентов.
Схожую тактику могли бы взять на вооружение специалисты, оказывающие частные услуги. Например, те же психотерапевты, взаимодействующие со своими пациентами не только в пределах клиники, но и из дома, используя Zoom, Skype или другие средства связи.
Сейчас процесс планирования встреч с доктором представляет собой переписку в WhatsApp или ВКонтакте. Пациент сообщает о том, что хочет попасть на прием, доктор отправляет ему список свободных дат. Клиент пропадает на несколько дней, а затем бронирует время приема, но дата оказывается уже занятой. Процедура затягивается, обе стороны теряют время впустую.
Если же доктор оставлял бы на своей личной странице ссылку на планировщик встреч или отправлял ее первым сообщением в условном WhatsApp, никому не пришлось бы тратить время и гадать, какое же время записи выбрать. Пациент сам нашел бы удобное время среди свободных дат, записался бы на прием и автоматически получил бы ссылку на встречу в Teams или его аналоге. А доктор мог бы не отвлекаться и полностью сосредоточиться на своей работе, не переживая о расписании и при этом принимая большее количество людей.
Естественно, никто не запрещает использовать Calendly и другие похожие инструменты в повседневной жизни. Например, можно договориться о встрече с друзьями и отправить им ссылку на свое расписание в планировщике встреч, где они укажут время встречи, место и другие важные подробности грядущего мероприятия. И все это за пару кликов без необходимости несколько дней обмениваться сообщениями или письмами.
Подобный инструмент может почти любому человеку заменить секретаря. Это эффективных механизм, не требующий никаких навыков и больших вложений. Шедулеры легко встраиваются в сайты и приложения, а ссылки на расписание можно просто отправлять почтой или СМС.
И таких бытовых сценариев применения может быть масса. Вы ограничены только собственной фантазией.
В РФ шедулеры непопулярны. Во-первых, как я уже отмечал выше, в некоторых CRM есть похожая функциональность, но она недоступна большинству пользователей. Во-вторых, существующие планировщики не адаптированы под работу в российских реалиях, и единицы из них поддерживают русский язык, да и то на весьма условном уровне (панель управления везде на английском).
Поэтому в России пока никто толком не смог внедрить планировщики встреч в свой бизнес, а стоило бы.
У нашей команды разработчиков как раз есть желание создать сервис, который стал бы аналогом Calendly в России, то есть удобным шедулером на русском языке, который адаптирован под реалии российского бизнеса.
И мы здесь с конкретным предложением. Уже сейчас вы можете пройти по ссылке и оставить заявку на сайте сервиса, чтобы войти в ряды первых пользователей нашего шедулера, причем еще и бесплатно.
Мы создали собственный планировщик встреч, который избавит вас от кучи проблем с планированием. Если вы хоть раз тратили время на урегулирование даты встречи или конференц-звонка, то должны знать, какая это боль.
Мы создали сервис, который упростит планирование и практически полностью его автоматизирует. Вам больше не придется совершать лишних действий – проект MakeMeet возьмет на себя все заботы, связанные с расписанием, а вы наконец полностью сможете сосредоточиться на работе. Причем независимо от того, менеджер вы в крупной корпорации, риэлтор или частный психотерапевт. MakeMeet для всех станет незаменимым инструментом.
Приглашаем на закрытое бета-тестирование нашего нового продукта! Первые 100 пользователей, оставивших заявку, смогут пользоваться сервисом бесплатно.
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, а не традиционную утилизацию (долю времени, когда система находилась в занятом состоянии).