Ускорение загрузки Windows 7. Инструкция для IT специалистов.

В интернете очень много советов по ускорению загрузки Windows на компьютере. Но все они либо примитивные, либо откровенно вредные. Ниже я распишу «фундаментальную» метод решения данной проблемы. Скажу сразу — описанное в данной статье применяйте только в том случае, если вы — IT специалист, либо имеете углубленные знания в Windows.

Итак, у вас под рукой компьютер, который нормально заряжен (Core iX, достаточное количество ОЗУ и SSD хард), но при этом, вас не устраивает то, что ваш компьютер загружается 1-2 минуты, либо по какой-то причине, он стал долго загружаться. При этом вы перепробовали все основные способы: удалили мусор, все лишнее из автозагрузки и все такое.


Если быть откровенным
Данную статью я стянул из одного ресурса в интернете. Просто чуточку устал постоянно искать ту ссылку, когда кто-то спрашивает у меня, как ускорить компьютер.

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

windows_speed_1

Собирать трейсы будем при помощи 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

И можно начинать просмотр. Увиденное навевает печаль:
windows_speed_2

Explorer готов к 36-й секунде, но из-за 100% загрузки единственного (не особо быстрого) диска, система еще 2 минуты будет не очень отзывчивой (меню пуск будет открываться мгновенно, а вот с запуском программ придется подождать).
ReadyBoot пытается чего то сделать и сначала у него даже получается (оранжевое и зеленое), но постепенно накапливающиеся отклонения от бутплана сводят его попытки на нет.
Что еще печальнее, так это то, что вместо собственно чтения данных, большую часть своей стопроцентной занятости диск проводит в метаниях головки к центру диска и обратно:

windows_speed_3

Небольшая справка: ReadyBoot собирает профиль использования диска при каждой загрузке и потом сервис SysMain строит бутплан на основании пяти последних загрузок. Соответственно, чем чаще загружаетесь, тем лучше будет «угадан» бутплан на следующую загрузку и тем быстрее она будет. Помимо этого, префетчер собирает статистику о том, какие файлы и в каком порядке были использованы во время загрузки и складывает эту информацию в %SystemRoot%\Prefetch\Layout.ini
Эту информацию использует встроенный дефрагментатор для принятия решений о размещении файлов.

Соответственно первой «оптимизацией» будет многократная перезагрузка и дефрагментация. Очень удобно, что xbootmgr может сделать это за нас.

xbootmgr -trace boot -prepSystem
По умолчанию выполняется шесть перезагрузок:

windows_speed_4


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

windows_speed_5

 Когда все закончится, в каталоге, из которого был запущен xbootmgr останется 6 файлов с трейсами каждой из подготовительных перезагрузок а также все тот же boot_BASE+CSWITCH_1.etl

Смотрим, изменилось ли чего нибудь. А все изменилось довольно заметно:
windows_speed_6

ReadyBoot справляется со своей задачей значительно лучше и как следствие эксплорер готов на треть быстрее, а время активности диска сократилось почти вдвое.

windows_speed_7

Мы все еще ходим в центр диска и этим мы займемся позже, но disk seek-ов уже заметно меньше, и это уже какой никакой, а успех. Пока же, обратим внимание на такой график:

windows_speed_8

Это же безобразие. Пока кто то выкладывается на 100%, некоторые отдыхают. Будем исправлять. Как обычно разменивают процессоное время на размер читаемых данных? Правильно, компрессией. Исправлять будем сжатием папок Windows и обоих Program Files-ов. Попытку сделать это из загруженной системы нельзя назвать успешной — какие то файлы пакуются, какие то нет. В общем так жить нельзя:

windows_speed_9

 


Перегружаемся в System Recovery и выполняем оттуда compact /c /a /i /s: каталог для наших трех каталогов. Скриншотов не будет, так как мне было сильно лень делать скриншотилку для WinPE — придется поверить на слово (а лучше перепроверить экспериментально). prepSystem придется провести еще раз, так как layout диска после сжатия сильно поменялся.

Ну и проверяем, чего у нас вышло-то:

windows_speed_10

Эксплорер готов к 20-й секунде, еще чуть меньше минуты идет дисковая активность, но уже чуть меньше 100%.
И да, мы все еще ходим в центр диска:

windows_speed_11

Тултипы подсказывают нам виновника. Перепроверям

windows_speed_12

Заодно под раздачу попадают скайп и стим. И правильно — нечего им делать в автозагрузке с такими аппетитами. Их всегда можно запустить из супербара/старт меню.

Последние штрихи.
Совершенно невменяемое время загрузки одного сервиса:

windows_speed_13


И второго:

windows_speed_14


Мы решили не отказываться от функционала, даже если он нам на фиг не уперся. Поэтому отключать сервисы мы не будем. Мы просто переключим их в «Automatic (Delayed start)»:

windows_speed_15


В случае с Microsoft Antimalware все несколько сложнее:

windows_speed_16


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

windows_speed_17


На всякий случай еще один prepSystem и вот финал:

windows_speed_18


Эксплорер загрузился на 17-й секунде, на 18-й фактически прекращается дисковая активность.
Можно полюбоваться на строго упорядоченный доступ к диску:

windows_speed_19

Быстрый SSD и/или тотальное вырезание функционала могло бы сократить время загрузки до десяти секунд и меньше.
А вывод из всего этого такой: прежде чем что либо «оптимизировать», стоит определить те минимальные изменения, которые возымеют максимальный результат.


Данная статья взята с Geektimes.
https://geektimes.ru/post/106684/

5
Отправить ответ

avatar
2 Comment threads
3 Thread replies
0 Followers
 
Most reacted comment
Hottest comment thread

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.

  Subscribe  
новые старые популярные
Уведомление
nikolas_sharp
Гость

Это просто очень круто! Ты работал по какой-то инструкции или всё сам разобрал? Потому что концептуального представления о том, как именно работает винда, в это деле, по-моему, применено немало.

nikolas_sharp
Гость

Аааа. Всё! Увидел приписку «Если быть откровенным» 🙂 . В любом случае спасибо, что поделился. Наконец более-менее понятный мануал с фундаментальным обоснованием действий вместо статей под ключевые слова от копЯрайтеров. Есть также предположение, что перевод с английского. Если вдруг знаешь первоисточник, то было бы интересно посмотреть, потому что по этому тексту местами ощущение либо слишком длинных пропусков, либо плохого перевода.