Правильная оптимизация загрузки Windows 7

Эту классную статью я нашел на Хабре, статья написана пользователем amirul.

Мое мнение, что это пока лучший step by step по оптимизации загрузки Windows 7. Далее сам текст:

Ускорение загрузки Windows for fun and profit

image Пожалуй начну с того, что если перегружаться 15 раз в год, то любой «тюнинг» процесса загрузки отнимает больше времени, чем будет выиграно на перезагрузках за все время жизни системы. Однако, спортивный интерес берет свое, тем более, что люди интересуется процессом оптимизации быстродействия. А загрузка оказалась самым очевидным кандидатом в примеры того, как на мой взгляд должен выглядеть этот самый процесс. Сразу скажу, что грузиться будем с 5400 rpm винта, грузиться будем в «рабочую» систему: помимо недобитой вендорской крапвари там стоит еще куча всякого типа вижуал студии, антивируса, скайпа, стима, гуглапдейтера и пр…

Про то, почему отключение pagefile-а скорее вредно, чем полезно — как нибудь в другой раз, а пока…


Конкретных и общеприменимых советов по оптимизации работы ОС быть не может точно так же как не может быть конкретных советов по ускорению работы любой случайно взятой программы. Точно так же как и в отдельных программах, работа всей системы может быть серьезно замедлена из-за одного-двух на первый взгляд незначительных мест. Для нахождения подобных «бутылочных горлышек» в программах существуют инструменты, называемые профайлерами. Нет ничего странного, что для нахождения «бутылочных горлышек» в операционной системе мы тоже будем использовать профайлер (никаких кавычек — это действительно профайлер причем одновременно и sampled и instrumented). С недавних пор WPA Tools распространяются в составе Windows SDK. Ставить полный SDK совершенно необязательно. Можно установить только «Windows Performance Toolkit»:

Собирать трейсы будем при помощи xbootmgr. Из магии используется только автологгер, включающий сбор ETW трейсов начиная с самого winload. Для вызова справки можно ввести xbootmgr -help — приводить ее здесь я не буду. Для желающих оценить масштаб можно ввести xperf -providers (или logman providers). Каждый провайдер имеет несколько «ключевых слов» (keywords), каждое «ключевое слово» включает/выключает несколько типов событий (event).

Итак начнем. Осторожно, следующая команда автоматически перегружает компьютер
xbootmgr -trace boot
После перезагрузки в каталоге, в котором эта команда была выполнена останется файл «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 -trace boot -prepSystem
По умолчанию выполняется шесть перезагрузок:

После второй начинается дефрагментация:

Когда все закончится, в каталоге, из которого был запущен 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 и/или тотальное вырезание функционала могло бы сократить время загрузки до десяти секунд и меньше.

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

Игорь Чишкала

Директор по технологиям в SoftForge. Люблю ИТ, пишу технические статьи в этом блоге или для сайта фриланс-биржи Upwork. Кодю на PHP с использованием фреймворков Laravel или Symfony.

4 Комментариев

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

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *