Десятки фоновых служб впустую жгут ресурсы и как перевести их на работу по запросу

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

Идея оптимизации проста и изящна: перевести службы, которые не нужны постоянно, на запуск по требованию. Тогда служба не стартует при загрузке и не висит балластом, а поднимается лишь в тот момент, когда её работа реально понадобилась, и засыпает, когда нужда отпала. Память освобождается, старт облегчается, ресурсы перестают тратиться впустую. Самое приятное, что система умеет делать это умно, поднимая нужную службу автоматически по нужному событию, так что пользователь даже не замечает разницы, кроме как в скорости и лёгкости работы машины.

Четыре типа запуска и что каждый из них означает

Чтобы управлять службами осознанно, надо понимать, какими вообще бывают режимы их запуска. Система предлагает несколько типов, и у каждого своя роль. Автоматический запуск означает, что служба стартует сразу при загрузке системы и работает с высоким приоритетом. Это режим для того, что нужно немедленно и постоянно, вроде ключевых системных функций. Но именно в этот режим по инерции попадает множество служб, которым постоянная работа вовсе не требуется, и тут кроется главный простор для оптимизации.

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

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

Управление типом запуска через командную строку

Графическая оснастка служб удобна для разовой правки, но для точной и массовой работы используют командную строку и инструмент управления службами. Узнать текущее состояние и настройки конкретной службы позволяет запрос, показывающий её тип запуска и прочие свойства:

sc qc "ИмяСлужбы"

В выводе видно, как служба настроена сейчас: запускается ли автоматически, вручную или отключена. Это отправная точка, ведь прежде чем что-то менять, надо понять исходное положение. Сама смена типа запуска делается командой настройки с указанием нужного режима. Перевод службы на запуск по требованию выглядит так:

sc config "ИмяСлужбы" start=demand

Здесь значение demand и означает запуск по требованию, то есть вручную. Для перевода в автоматический отложенный режим применяется другое значение, велящее службе стартовать после полной загрузки системы:

sc config "ИмяСлужбы" start=delayed-auto

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

sc config "ИмяСлужбы" start=disabled

Важная деталь синтаксиса: между параметром и его значением знак равенства окружён по-особому, и пробел ставится после равенства, а не до него. Эта мелочь не раз ставила в тупик тех, кто привык к обычному виду команд, ведь при неверной расстановке пробелов команда отвергается. Поэтому форму записи стоит соблюдать буквально, как она приведена, не переставляя пробелы по привычке.

Запуск и остановка служб на лету без перезагрузки

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

sc start "ИмяСлужбы"

Остановить работающую службу так же просто, указав остановку:

sc stop "ИмяСлужбы"

Существует и более старый, но привычный многим способ управлять службами на лету через команду сетевого управления, которая делает то же самое чуть иным синтаксисом:

net stop "ИмяСлужбы"
net start "ИмяСлужбы"

Эти команды бесценны, когда служба зависла или ведёт себя странно: остановил, запустил заново, и нередко проблема уходит без всякой перезагрузки. Сочетание управления типом запуска и управления состоянием на лету даёт полный контроль. Типом запуска решают, как служба будет вести себя впредь, а командами старта и остановки управляют ею прямо здесь и сейчас. Вместе они покрывают и стратегическую настройку, и оперативное вмешательство.

Умный запуск по событию и почему ручной режим не означает ручной труд

У многих возникает резонное опасение: если перевести службу на ручной запуск, не придётся ли поднимать её руками каждый раз, когда понадобится. Опасение это в большинстве случаев напрасно, и тут кроется главная прелесть современной системы служб. Ручной запуск вовсе не значит, что службу обязательно поднимает человек. Чаще её автоматически поднимает система, когда обнаруживает, что служба понадобилась, и так же тихо гасит, когда нужда отпала.

Работает это через механизм зависимостей и событий. Когда программа обращается к функции, за которую отвечает спящая служба, система видит запрос и сама поднимает нужную службу, а программа даже не замечает заминки. Многие службы вдобавок настроены на запуск по конкретным событиям: подключению устройства, появлению сети, обращению к определённому ресурсу. Такая служба спит, пока нужное событие не произошло, а затем мгновенно просыпается. Получается умная экономия: служба не висит впустую, но всегда готова подняться в нужный миг сама, без участия человека.

Именно этот механизм и делает перевод служб на запрос почти безболезненным. Балластная служба, переведённая в ручной режим, перестаёт жечь ресурсы при загрузке и в простое, но не теряет способности подняться, когда её функция реально понадобится. Человек не замечает никакого ручного труда, ведь поднимает службу не он, а сама система по запросу. Это и отличает грамотную оптимизацию от грубого отключения: служба не вырубается насовсем, а переводится в режим разумной готовности, экономя ресурсы без потери функциональности.

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

Какие службы трогать можно, а какие смертельно опасно

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

Первое правило: не трогать службы, назначения которых не понимаешь. Если непонятно, за что отвечает служба, разумнее оставить её в покое, чем рисковать. Многие службы, чьи имена ничего не говорят, на деле обеспечивают важнейшие функции, и их перевод в ручной режим может аукнуться неожиданными сбоями, причину которых потом замучаешься искать. Второе правило: менять режим по одной службе за раз и проверять, не сломалось ли что, прежде чем браться за следующую. Так при поломке сразу ясно, какая именно служба виновата, и легко вернуть всё назад.

Третье правило: всегда иметь путь к отступлению. Прежде чем массово менять службы, разумно запомнить или записать их исходные настройки, чтобы при беде вернуть как было. Хорошие кандидаты на перевод в ручной режим это службы оборудования, которого нет, и службы программ, которыми пользуются изредка. Плохие кандидаты это всё, что связано с безопасностью, сетью, ядром системы, входом в неё. Граница между ними не всегда очевидна, и при малейшем сомнении вернее перестраховаться. Лучше оставить лишнюю службу работать, чем превратить машину в кирпич ради пары мегабайт сэкономленной памяти.

Как узнать настоящее имя службы и где система его хранит

При работе из командной строки всплывает практическая загвоздка: команды требуют точного имени службы, а оно нередко отличается от того понятного названия, что показано в графической оснастке. У службы есть отображаемое имя, длинное и человеческое, и есть короткое системное имя, которым и оперируют команды. Перепутав их, легко получить ошибку, ведь команда не найдёт службу по красивому названию из списка. Поэтому первым делом выясняют настоящее короткое имя.

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

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

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

Перевод служб на запуск по требованию это тонкий и действенный инструмент оптимизации, но требующий уважения к рискам. В отличие от чистки автозапуска, где худшее последствие это незапустившаяся программа, неосторожность со службами способна повредить саму систему. Зато и награда весома: машина, избавленная от десятков впустую работающих служб, стартует легче, держит больше свободной памяти и тратит ресурсы только на то, что действительно используется. Умный механизм запуска по событию делает эту экономию незаметной для пользователя, поднимая нужные службы сами собой в нужный миг. Главное тут двигаться вдумчиво и по одной службе, уважая ту незримую опору, на которой держится вся работа системы.