18:41 Ускорение загрузки Windows for fun and profit | |
Конкретных и общеприменимых советов по оптимизации работы ОС быть не может точно так же как не может быть конкретных советов по ускорению работы любой случайно взятой программы. Точно так же как и в отдельных программах, работа всей системы может быть серьезно замедлена из-за одного-двух на первый взгляд незначительных мест. Для нахождения подобных «бутылочных горлышек» в программах существуют инструменты, называемые. Нет ничего странного, что для нахождения «бутылочных горлышек» в операционной системе мы тоже будем использовать (никаких кавычек — это действительно профайлер причем одновременно и sampled и instrumented). С недавних пор WPA Tools распространяются в составе . Ставить полный SDK совершенно необязательно. Можно установить только «Windows Performance Toolkit»:
Собирать трейсы будем при помощи xbootmgr. Из магии используется только , включающий сбор начиная с самого 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 и/или тотальное вырезание функционала могло бы сократить время загрузки до десяти секунд и меньше. А вывод из всего этого такой: Прежде, чем что либо «оптимизировать» стоит определить те минимальные изменения, которые возымеют максимальный результат | |
|
| |