Правильна оптимізація завантаження windows 7

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

Моя думка, що це поки найкращий step by step по оптимізації завантаження Windows 7. Далі сам текст:

Прискорення завантаження Windows for fun and profit

Мабуть почну з того, що якщо перевантажуватися 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 намагається чогось зробити і спочатку у нього навіть виходить (помаранчеве і зелене), але поступово накопичуються відхилення від бутплана зводять його спроби нанівець.
Що ще сумніше, так це те, що замість власне читання даних, більшу частину своєї стовідсоткової зайнятості диск проводить в метаннях головки до центру диска і назад:

Відео: Як прискорити завантаження Windows 7/8

Невелика довідка: ReadyBoot збирає профіль використання диска при кожному завантаженні і потім сервіс SysMain будує бутплан на підставі п`яти останніх завантажень. Відповідно, чим частіше завантажуєтесь, тим краще буде «вгаданий» бутплан на наступну завантаження і тим швидше вона буде. Крім цього, префетчер збирає статистику про те, які файли і в якому порядку були використані під час завантаження і складає цю інформацію в% SystemRoot% Prefetch Layout.ini
Цю інформацію використовує вбудований дефрагментатор для прийняття рішень про розміщення файлів.

Відео: Прискорення, оптимізація і запуск Windows 10

Відповідно першої «оптимізацією» буде багаторазова перезавантаження і дефрагментація. Дуже зручно, що 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 і / або тотальне вирізання функціоналу могло б скоротити час завантаження до десяти секунд і менше.

А висновок з усього цього такий:
Перш, ніж що або «оптимізувати» варто визначити ті мінімальні зміни, які матимуть максимальний результат