Scheduling agent что это

Yablor.ru – рейтинг блогов рунета, автоматически упорядоченных по количеству посетителей, ссылок и комментариев.

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

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

about_windows — 17.11.2013 Знаете чем отличается наличие в автозагрузке, например, утилиты Corel Registration Reminder и утилиты CPUcool??
Первая сделана для того, чтобы еженедельно донимать пользователя просьбами зарегистрироваться. А вторая обеспечивает программное охлаждение процессора. В то время когда вторая жизненно необходима для хорошей работы компьютера, то первая еженедельно убивает целый один нерв пользователя!!
Таких примеров, примеров абсолютно ненужных программ в автозагрузке, можно принести довольно много!
Отключение таких программ не только полезно для нервной системы, но и хорошо сэкономит ресурсы компьютера!

Все данные программы по умолчанию лезут в автозагрузку.
Access Ramp Monitor (armon32.exe) – отслеживает параметры интернет-соединения, запрещает запуск некоторых игр.
Album Fast Start (abmtsr.exe) – утилита для сканера, для его нормальной работы не требуется, доступна из меню "Пуск".
Alogserv (alogserv.exe) – утилита для ведения протокола работы McAfee VirusScan.
Сpost.exe – Microsoft TV Viewer Post Setup Program – часть Microsoft WebTV for Windows.
BrowserWebCheck (loadwc.exe) – проверяет, является ли Internet Explorer браузером, используемым по умолчанию. Не требуется.
ConMgr.exe (conmgr.exe) – запускает WinFax Pro, нужна для ответа на входящие звонки.
CtfMon (ctfmon.exe) – прописывается в автозагрузку при каждом запуске Office XP, нужна для альтернативных способов ввода текста, поэтому если диктовка не используется, то лучше отключить через апплет Text Services and Speech в Панели управления.
CyDoor (CT_Load.exe) – засасывающая рекламу spyware-утилита. Желательно удалить вместе с программой-маткой. Поможет в этом утилита AD-aware (www.lavasoft.de/aaw).
EM_EXEC (em_exec.exe) – драйвер мыши Logitech. Нужен для поддержки дополнительных функций мыши или трекбола.
Fpx (mnmsrvc.exe) – служба Remote Desktop Sharing, часть Microsoft NetMeeting.
Gator (gator.exe) – еще одна шпионско-рекламная программа.
HIDServ (hidserv.exe) – Human Interface Device Server, нужен, только если используется какое-то USB-аудиоустройство, например мультимедийная USB-клавиатура с регулятором громкости.
Internat (internat.exe) – индикатор раскладки клавиатуры в системной области панели задач. Для самого переключения не требуется.
LoadPowerProfile (powrprof.dll) – отвечает за управление питанием и загрузку соответствующих профилей. Обычно грузится два раза, и один из экземпляров можно отключить.
Machine Debug Manager (mdm.exe) – дебаггер, нужен разработчикам и тестерам ПО. Крайне рекомендуется отключить.
MDAC_runonce (runonce.exe) – ассоциировано с Microsoft Data Access Components (MDAC). Автозагрузка не требуется, но наличие на диске самой системной утилиты runonce.exe необходимо. Microsoft Office Shortcut Bar (msoffice.exe) – панель быстрого запуска, входящая в состав Office.
MOSearch (mosearch.exe) – утилита Fast Search в Office XP, аналогична FindFast из Office 2000. Потребляет много ресурсов, лучше отключить, если не работаете с тысячами документов.
MSBB (msbb.exe) – очередная шпионская программа, загружает рекламу на ПК и шпионит за пользователем. Отключайте.
MSConfigReminder (msconfig.exe) – при загрузке ОС сообщает, что вы что-то отключили в программе "Настройка системы".
Netzip Smart Downloader (npnzdad.exe) – spyware-утилита, закачивает рекламу на ПК без ведома пользователя и отслеживает его действия.
New.net (rundll32.exe NewDotNetStartup) – опять шпион.
PCHealth (pchschd.exe) – в Windows Me планировщик системы PC Health, при отмене его загрузки PC Health не отключается.
PWSTray (pwstray.exe) – Microsoft Personal Web Server, можно запустить и вручную.
QuickSort (qsort.exe) – утилита для сортировки пунктов меню "Пуск" по алфавиту – не требуется.
RealDownload Express (npnzdad.exe) – снова любитель качать рекламу на компьютер.
Resource Meter (rsrcmtr.exe) – индикатор ресурсов Windows, можно запускать вручную.
SaveNow (savenow.exe) – опять рекламный шпион.
ScanRegistry (scanregw.exe) – системный сканер реестра, делает также его резервные копии. Очень ценная вещь, в памяти не остается.
SchedulingAgent (mstask.exe) – "Планировщик заданий". Если не используется – отключить.
StateMgr (statemgr.exe) – отвечает в Windows Me за службы System Restore и System File Protection – если они не требуются, то можно отключить.
Synchronization Manager (mobsync.exe) – Internet Explorer Synchronization Manager – для повседневной работы не нужен.
SystemTray (systray.exe) – System Tray Services, выводит в системной области панели задач значки Volume Control, PC Card Status и Power Management.
TaskMonitor (taskmon.exe) – отслеживает ход запуска программ и поставляет эти данные дефрагментатору для оптимизации расположения файлов на диске. Полезная вещь.
TimeSink Add Client (tsadbot.exe) – один из самых распространенных шпионов.
W3KNetwork (rundll32.exe w3knet.dll,dllinitrun) – очередное spyware.
Winmodem (wmexe.exe) – нужен для функционирования некоторых вин-модемов.

Список составлен не мной, а взят в одном хорошем справочнике. Возможно, у Вас не окажется ни одной из этих программ. Но суть, которую я бы хотел довести в том, что с вниманием рассмотрите программы, которые запускаются вместе с ОС. Очень многие из них Вы найдете совсем необязательными.
Просто найдите тот файл, который прописан в автозагрузку, посмотрите его свойства, его имя, папку, в которой он лежит, в крайнем случае загуглите, но узнайте приблизительно что делает данная программа. И сделайте вывод, нужна ли она Вам!!

Размещение сквозной ссылки

Если у Вас меньше 64 мегабайт оперативной памяти (ОЗУ), то работать в WINDOWS 98 – сущая мука. Лучшим средством от этого является покупка дополнительной памяти, но в этой статье описаны способы разгрузки и без того полной оперативной памяти.

Заранее скажу, что компьютер не станет «летать», как у «нового русского» соседа, все зависит от конфигурации Вашей «коптилки».

Огромное количество памяти «съедают» многочисленные агенты, проверки, антивирусы. Для начала посмотрим, что у нас находится в папке «автозагрузка». Нажмем пуск->программы->автозагрузка. Смело убираем оттуда «быстрый запуск Microsoft Office». «Поиск файлов» тоже бесполезен, а «съедает» много памяти. Теоретически он должен помогать искать файлы, но на практике без него ничуть не хуже. Без панели Офиса тоже можно обойтись, лично у меня ярлыки WORD, EXEL, и т.д. на рабочем столе, так даже удобней. Различные антивирусы, проверки, агенты, которые, кстати, занимают своими значками место слева от часов, занимают больше мегабайта ОЗУ.

Но даже когда вы очистите папку автозагрузка, перезагрузите компьютер и в винде нажмете святую троицу CTRL+ALT+DEL, вы увидите еще несколько загруженных в ОЗУ приложений. Чтобы «разделаться» с ними, нужно запустить специальную программу настройки системы, которая входит в комплект поставки WINDOWS 98 и на удивление удобна и продумана программистами. Заходим в меню Пуск, щелкаем на команду Выполнить.

В появившемся окне вводим msconfig, нажимаем ОК. Запустится программа, на вкладке Общие->выборочный запуск можно выбрать обрабатываемые файлы при загрузке системы. Далее на вкладках файлов Autoexes.Bat и Config.sys отмечаются строчки, которые запускаются еще до загрузки WINDOWS. На следующей вкладке можно выделить исполняемые строки в файле Win.ini, который загружается вместе с WINDOWS и содержит в себе большое количество настроек. Следующая вкладка – та самая, которая управляет процессом загрузки системы и ОЗУ.

В этой программе можно выгрузить из памяти все неиспользуемые задачи.

Первая из них – internat. Это – индикатор раскладки клавиатуры. Он довольно небольшой по объему, но если очень нужно, его можно убрать.

Следующий – SystemTray. Он вам совершенно не нужен, так как это индикатор заряда батарей, смело его убирайте.

Очень не рекомендуется убирать флажок на ScanRegistry. Эта программа при запуске «окошек» проверяет и создает резервную копию системного реестра, но если вы все-таки убрали этот пункт, не забывайте резервировать реестр почаще с помощью программы scanregw (её нужно ввести в окне Пуск->Выполнить…)

TaskMonitor – создаёт список запущенных вами файлов и приложений, чтобы использовать это при дефрагментации диска. Удовольствие это сомнительное, так как большинство людей с их объемами жестких дисков давно уже перестали совершать эту процедуру. (Лично я терплю 1,5-2 часа скрежета «винта», дальше вырубаю этот «дефраг»)

SchedulingAgent – планировщик заданий. Без комментариев. Но его можно убрать проще: нажать на его ярлыке в панели задач правую кнопку мыши, и в появившемся контекстном меню выбрать приостановить планировщик.

Не устанавливайте в систему различные устройства, которых у вас нет. К ним требуются драйверы, «поедающие» оперативную память и время загрузки.

Напоследок расскажу о своп-файле. В идеале у вас должно быть столько памяти, сколько требует система и загруженные приложения. Но такое видел только Билл Гейтс и то во сне. За недостатком система обращается к жесткому диску. Поскольку у них скорость, как у оперативной памяти, будет ещё не скоро, то обмен данными происходит на очень медленном уровне.

У большинства пользователей стоит автоматический выбор параметров виртуальной памяти. Это очень большой объем, которым система пользуется не рационально, постоянно фрагментирует. Поэтому объем «свопа» нужно сделать фиксированным. Щелкаем правой кнопкой мыши на мой компьютер-> свойства->вкладка быстродействие, нажимаем на кнопку виртуальная память. Выставляем параметры, приблизительно равные минимум – одному объёму ОЗУ, максимум – 2,5-3 объемам. Этого хватит, если вы, конечно, не запускаете несколько жадных до памяти приложений одновременно.

Все. Надеюсь, что мои советы хоть как-то помогли вам и вашему компьютеру.

Если у вас есть какие-либо вопросы, пишите на e-mail: мне .

В последние пару лет я занимаюсь построением различных планировщиков, и мне пришло в голову поделиться своим нелёгким опытом с коллегами. Речь идёт о двух категориях коллег. Первые — это желающие узнать, как разработать свой 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 раз хуже. Мало того, что от этой секунды никуда ни деться, так ещё и в реальной системе обязательно встретятся другие проблемы:

• Непредсказуемое переменное число пользователей — если их окажется не 100, а 1000, то ждать придётся 10 с.
• Высокая стоимость переключения контекста. Например, если планировать запросы к HDD, то переключение между пользователями может подразумевать seektime на уровне 8 мс и, как следствие, приводить к максимальному ожиданию 800 мс, уменьшению полосы диска и росту очередей у всех пользователей.
• Часто такие Вити хотят сделать не один запрос, а присылают их помногу. Запросы скапливаются в очереди перед шедулером и ждут друг друга.
• Прочий приоритетный трафик.
• Не самый лучший из известных науке шедулер может вносить дополнительную задержку (конкретные числа и формулы ищите по ключевым словам latency-rate server).

Миф №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 выполнит задачи до дедлайнов.

Но есть условия, при которых стройная картина мира рушится и система перестаёт укладываться в дедлайны.

Overrun. В hard-RT-системах предполагается, что мы знаем, сколько задача будет выполняться в худшем случае. Однако в неидеальном мире это не так, и завершение задачи может потребовать больше времени. Если мы позволим задаче выполняться дольше положенного, то поставим под угрозу выполнимость других задач. В случае с EDF возникнет эффект домино.

• Overload. Не исключено, что вновь пришедшая задача не укладывается в желаемые сроки. Если мы примем её к выполнению, то опять получим эффект домино. Обычно в подобных случаях констатируют перегрузку системы и принимают меры, чтобы её устранить. Например — отказывают новой или каким-то текущим задачам в выполнении. Ещё один вариант — схема с пересмотром гарантий и откладыванием дедлайнов некоторых задач.

Таким образом, EDF, если это возможно, выполняет дедлайны, а если невозможно — наносит процессу максимум ущерба. Скажем по-другому: минимизируя максимальное запаздывание, EDF проваливает дедлайны у максимально большого количества задач. EDF не стоит напрямую применять в условиях перегрузки — которую, как оказывается, зачастую проблематично предсказать и/или предотвратить. Однако способы борьбы всё же существуют.

Миф №8. Систему нельзя загрузить больше чем на 100%

Для определения загрузки (load factor) в RT-системах используется простая периодическая модель следующего вида. Есть задачи, которые поступают раз в T_i мс и требуют эксклюзивного владения ресурсом в течение C_i мс в худшем случае. Тогда load factor определяется как запрошеное время ресурса на одну секунду реального времени, то есть U = C₁/T₁ +… + C_n/T_n. В такой простой модели всё понятно, но как подсчитать load factor, если у нас нет никаких периодов, а есть только текущие задачи и их дедлайны?

Тогда load factor определяется иначе. Текущие задачи сортируются по дедлайнам. Далее, начав с одного запроса с наименьшим дедлайном во множестве M, проходим по всем запросам и добавляем их в это множество. М на каждом шаге содержит запросы, которые должны быть полностью выполнены к определённому моменту времени t. Делим их суммарную остаточную стоимость (если вдруг мы уже частично выполнили какие-то из них) на оставшееся время t – now. Полученная величина — load factor U множества M. Чтобы получить текущий load factor, остаётся найти максимум из всех полученных U. Найденная величина, как несложно догадаться, сильно меняется во времени и легко может оказаться больше 1. Расписание невыполнимо c помощью EDF тогда и только тогда, когда load factor > 1.

Если вам важно соблюдать дедлайны, то в качестве метрики, за которой стоит следить, нужно использовать описанный load factor, а не традиционную утилизацию (долю времени, когда система находилась в занятом состоянии).

Adblock
detector