Функция отложенного запуска: новые возможности для служб Windows
В Windows Server 2008, Windows Vista и Windows 7 появилась новая опция запуска служб: «Автоматически (отложенный запуск)» (Automatic (Delayed Start)). Она позволяет решить описанную выше проблему с запуском приложения, которое требует подключения к базе данных на этом же сервере для корректного функционирования. Для сервера базы данных в таком случае следует выбрать традиционный режим автоматического запуска, а для приложения — режим отложенного запуска.
Опция отложенного запуска позволяет оптимизировать процесс загрузки системы и облегчает настройку приложений для последовательной автозагрузки. Процесс настройки отложенного запуска для служб ничем не отличается от традиционного (рис. A).
Настроить отложенный запуск можно не только посредством графического интерфейса, но и в реестре, изменив значение параметра Dword в разделе «DelayedAutoStart». При этом все стандартные службы, работающие в автоматическом режиме, запущены не будут: службам, для которых выбран отложенный запуск, просто будет присвоен пониженный приоритет.
Процесс настройки отложенного запуска для служб Windows описывается в блоге TechNet.
В предыдущих версиях Windows при загрузке системы процесс диспетчера сеансов (Session Manager, SMSS.EXE) запускал клиент-серверную подсистему (Client-Server Runtime Subsystem, CSRSS.EXE) и процесс входа в систему (WINLOGON.EXE). Последний запускал процесс сервера проверки подлинности локальной системы безопасности (Local Security Authority Subsystem Service, LSASS.EXE) и диспетчер управления службами (Service Control Manager, SERVICES.EXE). При консольном входе пользователь подключался к сеансу 0 (Session 0), который использовался и системными процессами. Недостаток такого подхода заключался в том, что при наличии у некорректно составленной службы Windows, запущенной в сеансе 0, пользовательского интерфейса в интерактивной консоли, вредоносное программное обеспечение могло атаковать данное окно с использованием сообщений и получить административные права.
Чтобы решить эту проблему, некоторые системные процессы в Windows Vista и Windows Server 2008 были усовершенствованы. SMSS.EXE, как и в предыдущих версиях, по-прежнему является первым пользовательским процессом, запускаемым при загрузке системы. Однако теперь он запускается в двух экземплярах, один из которых отвечает за настройку сеанса 0 для системных процессов. Экземпляр SMSS.EXE, отвечающий за сеанс 0, запускает приложение инициализации Windows (Windows Startup Application, WININIT.EXE) и экземпляр CSRSS.EXE для сеанса 0, а затем завершается. WININIT.EXE продолжает загрузку, запуская SERVICES.EXE и LSASS.EXE, а также новый процесс — диспетчер локальных сеансов (Local Session Manager, LSM.EXE), управляющий подключениями терминального сервера на данном компьютере.
Одновременно с сеансом 0 инициализируется сеанс консоли (Console session). Первый экземпляр SMSS.EXE создает новую копию самого себя для настройки сеанса консоли, как и в случае с сеансом 0. Новый экземпляр SMSS.EXE запускает CSRSS.EXE и WINLOGON.EXE для сеанса консоли, готовя систему к входу пользователя. После этого WINLOGON.EXE запускает хост-интерфейс входа пользователя (Logon User Interface Host, LOGONUI.EXE), который, в свою очередь, выводит окно «Параметры безопасности» (Windows Security) с предложением нажать [Ctrl]+[Alt]+[Delete] для входа.
Здесь стоит сказать несколько слов о процессе Winlogon. В прошлых версиях Windows процесс WINLOGON.EXE запускал библиотеку DLL графической идентификации и проверки подлинности (Graphical Identification and Authentication, GINA), указанную в реестре, для вывода интерфейса входа в систему с предложением ввести данные учетной записи пользователя. В Windows Vista и Windows Server 2008 библиотека GINA не используется — вместо нее реализована новая архитектура поставщиков учетных данных (Credential Provider). WINLOGON.EXE запускает LOGONUI.EXE для загрузки поставщиков учетных данных, которые настраиваются в разделе реестра «HKLM\Software\Microsoft\Windows NT\CurrentVersion\Authentication\Credential Providers». LogonUI управляет пользовательским интерфейсом и может последовательно запускать несколько поставщиков учетных данных. Поставщики учетных данных могут использоваться для вывода на экран входа в систему определенных элементов. LOGONUI.EXE передает данные учетной записи пользователя процессу WINLOGON.EXE и завершается.
При попытке входа в систему первый экземпляр SMSS.EXE создает новую копию самого себя для настройки нового сеанса, как в случае с сеансом 0 и сеансом консоли. Новый экземпляр SMSS.EXE запускает процессы CSRSS.EXE и WINLOGON.EXE для нового сеанса. WINLOGON.EXE запускает LOGONUI.EXE для вывода экрана входа в систему. На первый взгляд может показаться, что такой механизм создает излишнюю нагрузку на систему. На клиентских компьютерах особой пользы от этого действительно нет. Но в случае с терминальными серверами Windows Server 2008, возможность одновременного выполнения нескольких экземпляров SMSS.EXE ускоряет процесс входа в систему для нескольких пользователей одновременно.
Теперь расскажем вкратце о другой новой функции Windows Vista и Windows Server 2008 — отложенном запуске системных служб. Данная опция позволяет решить проблему автоматического запуска большого числа служб, создающих серьезную нагрузку при старте системы. Теперь те службы, запуск которых в самом начале процесса загрузки системы необязателен, стартуют в отложенном режиме, что существенно ускоряет процесс. Службы, для которых выбрана данная опция, запускаются вскоре после загрузки системы.
Как же действует новая функция? Диспетчер управления службами запускает службы, для которых выбран отложенный запуск, после загрузки цепочки процессов, отмеченных для автозапуска. Цепочке служб, запускаемых в отложенном режиме, присваивается приоритет THREAD_PRIORITY_LOWEST, и соответственно, все операции ввода/вывода, инициируемые данными службами, имеют самый низкий приоритет. После инициализации службы диспетчер управления службами вновь присваивает ей нормальный приоритет.
Сочетание отложенного запуска, пониженного приоритета для ЦП, оперативной памяти и фоновых операций ввода/вывода, значительно снижает нагрузку на систему, не препятствуя нормальному входу пользователя. Многие службы Windows, включая фоновую интеллектуальную службу передачи (Background Intelligent Transfer Service, BITS), клиент Центра обновления Windows (Windows Update Client) и службу Windows Media Center, теперь запускаются в отложенном режиме, чтобы ускорить процесс входа в систему при загрузке. Чтобы настроить службу для автоматического запуска в отложенном режиме, следует создать параметр REG_DWORD с именем «DelayedAutoStart» в подразделе конфигурации для данной службы в разделе «HKLM\SYSTEM\CurrentControlSet\Services».
Автор: Rick Vanover
Перевод SVET
Оцените статью: Голосов
Ускорение загрузки Windows for fun and profit
Пожалуй, начну с того, что если перегружаться 15 раз в год, то любой «тюнинг» процесса загрузки отнимает больше времени, чем будет выиграно на перезагрузках за все время жизни системы. Однако, спортивный интерес берет свое, тем более, что люди интересуется процессом оптимизации быстродействия. А загрузка оказалась самым очевидным кандидатом в примеры того, как на мой взгляд должен выглядеть этот самый процесс. Сразу скажу, что грузиться будем с 5400 rpm винта, грузиться будем в «рабочую» систему: помимо недобитой вендорской крапвари там стоит еще куча всякого типа вижуал студии, антивируса, скайпа, стима, гуглапдейтера и пр…
Про то, почему отключение pagefile-а скорее вредно, чем полезно — как нибудь в другой раз, а пока…
Конкретных и общеприменимых советов по оптимизации работы ОС быть не может точно так же как не может быть конкретных советов по ускорению работы любой случайно взятой программы. Точно так же как и в отдельных программах, работа всей системы может быть серьезно замедлена из-за одного-двух на первый взгляд незначительных мест. Для нахождения подобных «бутылочных горлышек» в программах существуют инструменты, называемые профайлерами. Нет ничего странного, что для нахождения «бутылочных горлышек» в операционной системе мы тоже будем использовать профайлер (никаких кавычек — это действительно профайлер причем одновременно и sampled и instrumented). С недавних пор WPA Tools распространяются в составе Windows SDK. Ставить полный SDK совершенно необязательно. Можно установить только «Windows Performance Toolkit»:
После перезагрузки в каталоге, в котором эта команда была выполнена останется файл «boot_BASE+CSWITCH_1.etl» (BASE+CSWITCH это те самые «ключевые слова»): xperf boot_BASE+CSWITCH_1.etl
И можно начинать просмотр. Увиденное навевает печаль:
Explorer готов к 36-й секунде, но из-за 100% загрузки единственного (не особо быстрого) диска, система еще 2 минуты будет не очень отзывчивой (меню пуск будет открываться мгновенно, а вот с запуском программ придется подождать). ReadyBoot пытается чего то сделать и сначала у него даже получается (оранжевое и зеленое), но постепенно накапливающиеся отклонения от бутплана сводят его попытки на нет.
Что еще печальнее, так это то, что вместо собственно чтения данных, большую часть своей стопроцентной занятости диск проводит в метаниях головки к центру диска и обратно:
Небольшая справка: ReadyBoot собирает профиль использования диска при каждой загрузке и потом сервис SysMain строит бутплан на основании пяти последних загрузок. Соответственно, чем чаще загружаетесь, тем лучше будет «угадан» бутплан на следующую загрузку и тем быстрее она будет. Помимо этого, префетчер собирает статистику о том, какие файлы и в каком порядке были использованы во время загрузки и складывает эту информацию в %SystemRoot%\Prefetch\Layout.ini
Эту информацию использует встроенный дефрагментатор для принятия решений о размещении файлов.
Соответственно первой «оптимизацией» будет многократная перезагрузка и дефрагментация. Очень удобно, что xbootmgr может сделать это за нас.
После второй начинается дефрагментация:
Когда все закончится, в каталоге, из которого был запущен xbootmgr останется 6 файлов с трейсами каждой из подготовительных перезагрузок а также все тот же boot_BASE+CSWITCH_1.etl
Смотрим, изменилось ли чего нибудь. А все изменилось довольно заметно:
ReadyBoot справляется со своей задачей значительно лучше и как следствие эксплорер готов на треть быстрее, а время активности диска сократилось почти вдвое.
Мы все еще ходим в центр диска и этим мы займемся позже, но disk seek-ов уже заметно меньше, и это уже какой никакой, а успех. Пока же, обратим внимание на такой график:
Это же безобразие. Пока кто то выкладывается на 100%, некоторые отдыхают. Будем исправлять. Как обычно разменивают процессоное время на размер читаемых данных? Правильно, компрессией. Исправлять будем сжатием папок Windows и обоих Program Files-ов. Попытку сделать это из загруженной системы нельзя назвать успешной — какие то файлы пакуются, какие то нет. В общем так жить нельзя:
Перегружаемся в System Recovery и выполняем оттуда compact /c /a /i /s: каталог для наших трех каталогов. Скриншотов не будет, так как мне было сильно лень делать скриншотилку для WinPE — придется поверить на слово (а лучше перепроверить экспериментально). prepSystem придется провести еще раз, так как layout диска после сжатия сильно поменялся.
Ну и проверяем, чего у нас вышло-то:
Эксплорер готов к 20-й секунде, еще чуть меньше минуты идет дисковая активность, но уже чуть меньше 100%.
И да, мы все еще ходим в центр диска:
Тултипы подсказывают нам виновника. Перепроверям
Заодно под раздачу попадают скайп и стим. И правильно — нечего им делать в автозагрузке с такими аппетитами. Их всегда можно запустить из супербара/старт меню.
Совершенно невменяемое время загрузки одного сервиса:
Мы договорились не отказываться от функционала, даже если он нам на фиг не уперся. Поэтому отключать сервисы мы не будем. Мы просто переключим их в «Automatic (Delayed start)»:
В случае с Microsoft Antimalware все несколько сложнее:
Достаточно быстро выясняем, что дело в том, что сервис относится к группе «COM Infrastructure» и не может быть загружен позже этой группы. Идем в реестр и вытаскиваем его из этой группы, после чего спокойно доделываем дело:
На всякий случай еще один prepSystem и вот финал:
Эксплорер загрузился на 17-й секунде, на 18-й фактически прекращается дисковая активность.
Можно полюбоваться на строго упорядоченный доступ к диску:
Быстрый SSD и/или тотальное вырезание функционала могло бы сократить время загрузки до десяти секунд и меньше.
А вывод из всего этого такой: прежде чем что либо «оптимизировать», стоит определить те минимальные изменения, которые возымеют максимальный результат.
«Автомат» против «автоматически (отложенный запуск)»
при установке служб Windows есть два варианта автоматического запуска службы Windows при запуске Windows. Один из них автоматическая, а другой автоматически (отложенный запуск). В чем разница между этими двумя поподробнее?
например, если вы создаете установщик с помощью wixtoolset, то ServiceConfig элемента
1 ответ:
короче говоря, услуги установлены в автоматическая запустится во время процесса загрузки, а службы будут запущены как задержана начнется вскоре после загрузки.
запуск вашего сервиса задержана повышает скорость загрузки вашего сервера и имеет преимущества безопасности, которые изложены в статьи Адриано связан с в комментариях.
обновление: «вскоре после загрузки» на самом деле через 2 минуты после по умолчанию запущена последняя «автоматическая» служба. Это можно настроить с помощью раздела реестра, согласно Внутренние Устройства Windows и других источников (3,4).
разделы реестра, представляющие интерес (по крайней мере, в некоторых версиях windows) являются: HKLM\SYSTEM\CurrentControlSet\services\ \DelayedAutostart будет иметь значение 1 если задерживается, 0 если не.
HKLM\SYSTEM\CurrentControlSet\services\AutoStartDelay десятичное число секунд для ожидания, возможно, потребуется создать этот. Применяется глобально ко всем задержана услуги.
Программирование служб Windows 7 с триггерами (ч.1)
Мы предпочитаем считать службы запущенными задачами, работающими в фоновом режиме и не затрагивающими операции пользователя. Службы в Windows отвечают за все виды фоновой активности, начиная со службы Remote Procedure Call (RPC), Printer Spooler и вплоть до службы Network Location Awareness.
Во-вторых, эти растрачиваемые ресурсы непосредственным образом сказываются на потреблении электроэнергии. Чем больше нагрузки мы даем на ЦП, тем больше электроэнергии компьютер потребляет. Это может быть критически важно для ноутбуков и может сократить время работы батареи на несколько часов.
В-третьих, постоянная работа непродуктивного программного обеспечения может привести к утечкам памяти и общей нестабильности системы. Это может привести к сбою в работе приложения и, в конце концов, компьютера.
Учитывая все вышесказанное, вы можете удивиться, почему так много разработчиков настраивают свои службы на постоянную работу, если у них имеется другая возможность. Даже до Windows 7 было доступно несколько вариантов запуска служб:
К сожалению, многие ISV (включая саму Microsoft) продолжают настраивать свои службы на автоматический (Automated) или автоматический отложенный запуск (Automatic Delayed), поскольку для всех это представляется простейшим решением. Служба просто работает 24х7 и всегда доступна, устраняя любую необходимость проверки зависимостей или того, запущена ли служба.
Можно привести множество примеров существующих служб, которые могут расходовать куда меньше ресурсов и стать безопаснее, не работая 24х7. Например, подумайте о службе обновлений, которая проверяет наличие новых обновлений для приложения. Если компьютер не подключен к сети и не имеет IP-адреса, зачем работать этой службе? Она ничего не может сделать, так зачем оставлять работающей программу, которая ничего не делает? Подумайте о службе управления политиками, которая используется при изменении групповых политик или при подключении компьютера к домену или отключении от него, но сейчас, когда компьютер подключен к моей домашней сети, служба, опять же, работает впустую.
Появление служб с запуском по триггеру
Решение вышеуказанных проблем заключается в выведении службы из «состояния постоянной работы» в другие виды фоновой активности, такие как запланированные задачи или службы, запускаемые триггером. Эта статья посвящена Windows 7 Trigger Start Services. О Windows 7 Scheduled Tasks можно сказать очень много полезного, что и будет сделано в последующих статьях.
Службы, запускаемые по триггеру (англ. trigger-start service), впервые появились в Windows 7. По сути, это обычная служба, которую вы можете настроить на запуск (или остановку) в случае срабатывания триггера, то есть в определенном случае или состоянии, которые вы сами задаете (например, когда становится доступным IP-адрес или когда он исчезает). Ниже приведен список доступных триггеров, с помощью которых вы можете настроить режим запуска вашей службы:
Последний пункт указывает на расширяемость. Будучи разработчиком, вы можете настроить любое событие ETW в качестве триггера для службы, что дает вам очень хороший инструмент для управления запуском и остановкой служб вашего приложения.
Так что же такое триггер?
Триггер состоит из:
Работа с Trigger Start Services
К сожалению, в пользовательском интерфейсе консоли Windows 7 Services MMC нет графического представления Trigger Start Services. Однако у вас есть две возможности. Вы можете по-прежнему использовать старый добрый sc.exe (программа командной строки Service Configuration) или воспользоваться методом WIN32 ChangeServiceConfig2 для программной настройки опций запуска службы, как будет показано в этой статье.
Использование SC.exe для запроса данных триггера службы (Query Service Trigger Information)
Пора повеселиться. Начнем с получения сведений о конфигурации некоторых служб. Общая форма для использования конфигурации службы выглядит следующим образом:
[ist]1. Откройте меню «Пуск».
2. Введите CMD в поле поиска.
3. Выберите cmd.exe.
4. Введите sc qtriggerinfo w32time и нажмите клавишу ввода.
Вот, как это должно выглядеть:
Как вы можете видеть, мы запросили данные триггера службы W32time, которая настроена на запуск при подключении компьютера к домену и остановку при отключении от домена.
Microsoft в Windows 7 обновила приложение командной строки sc.exe для поддержки конфигурации и получения сведений о поддерживаемых триггерах. Введите sc triggerinfo в окне Windows Shell и нажмите клавишу ввода. Результат будет похож на тот, что приведен ниже, и будет содержать все триггеры и сведения о том, как настроить службы на их использование.
ПАРАМЕТРЫ:
start/device/UUID/HwId1/.
start/custom/UUID/data0/..
stop/custom/UUID/data0/.
start/strcustom/UUID/data0/..
stop/strcustom/UUID/data0/..
start/networkon
stop/networkoff
start/domainjoin
stop/domainleave
start/portopen/параметр
stop/portclose/параметр
start/machinepolicy
start/userpolicy
delete
Программная настройка Trigger Start Services при помощи ChanceServiceConfig2
Более интересным с точки зрения разработчиков аспектом является создание служб, зависящих от триггера, и использование кода для конфигурации службы. В Windows 7 вы можете использовать функцию ChangeServiceConfig2 для настройки данных триггера службы и функцию QueryServiceConfig2 для их вызова.
BOOL _SetServiceToStartOnDeviceTrigger()
<
BOOL fResult = FALSE;
SC_HANDLE hScm = OpenSCManager(
NULL, //local machine
NULL, //active database
SC_MANAGER_CONNECT);
LPCWSTR lpszDeviceString = L»USBSTOR\\GenDisk»;
SERVICE_TRIGGER_SPECIFIC_DATA_ITEM deviceData = <0>;
deviceData.dwDataType = SERVICE_TRIGGER_DATA_TYPE_STRING;
deviceData.cbData =
(wcslen(lpszDeviceString)+1) * sizeof(WCHAR);
deviceData.pData = (PBYTE)lpszDeviceString;
SERVICE_TRIGGER st;
st.dwTriggerType =
SERVICE_TRIGGER_TYPE_DEVICE_INTERFACE_ARRIVAL;
st.dwAction = SERVICE_TRIGGER_ACTION_SERVICE_START;
st.pTriggerSubtype = (GUID *) &GUID_USBDevice;
st.cDataItems = 1;
st.pDataItems = &deviceData;
SERVICE_TRIGGER_INFO sti;
sti.cTriggers = 1;
sti.pTriggers = &st;
sti.pReserved = 0;
fResult = ChangeServiceConfig2(
hService,
SERVICE_CONFIG_TRIGGER_INFO,
&sti);
>
CloseServiceHandle (hService);
>
CloseServiceHandle (hScm);
if(!fResult)
<
printf(«Service trigger registration failed (%d)\n»,
GetLastError());
>
return fResult;
>
SERVICE_TRIGGER_SPECIFIC_DATA_ITEM задает тип события триггера. Он содержит данные о событии триггера службы. В нашем случае, мы задаем строку, описывающую подключение USB-диска.
Затем мы задаем структуру SERVICE_TRIGGER, которая представляет события триггеру службы. Заметьте, что именно здесь мы задаем тип триггера (подключение устройства), действие (запуск службы), и подтип триггера (определенный род USB-дисков). Следом мы определяем конкретное устройство, которое будет вызывать службу. Заметьте, что вы можете задать список устройств и их GUID. Также следует отметить, что мы не хотим срабатывания триггера запуска службы при подключении любого USB-устройства, как то мышь или камера. Мы хотим, чтобы служба запускалась только при появлении USB-диска.
Наконец, мы задаем структуру SERVICE_TRIGGER_INFO, которая содержит данные события триггера службы. Эта структура просто указывает на структуру SERVICE_TRIGGER, которую мы задали ранее, и количество триггеров, число которых в данном случае равно одному.
Теперь мы можем вызвать функцию ChanceServiceConfig2 и пройти дескриптор к службе, которую мы хотим настроить, параметр SERVICE_CONFIG_TRIGGER_INFO, который указывает, что мы хотим настроить триггер службы, и Null.
Вот и все. Если вы все сделали правильно, то служба запуститься при подключении USB жесткого диска.
Вы можете узнать больше о Windows 7 при помощи Windows 7 Training Kit for Developers или просмотрев видео, посвященные Windows 7, на Channel 9.
Вы также можете потренироваться в работе с Windows 7 Trigger Start Services при помощи тренинга Windows 7 Online, являющегося частью Channel 9 Learning Center.
Ссылки по теме
| Помощь |
 | |
| Задать вопрос | |
| программы | |
| обучение | |
| экзамены | |
| компьютеры | |
| |