Выберите Summary Table на Generic Events в самом низу — там много интересного.
Вот здесь в частности видно, как на 45-й миллисекунде загружается этот самый winload.exe (то есть event-ы идут начиная с бутсектора, а не winload)
На самом деле это, пожалуй, все что можно получить из преядерного трейса — они ничего не знают ни о настройках ни даже о файлах — складывают в память все чего есть и потом передают ядру в составе loader_block (или как бишь он там называется)
Дык они выпущены в один день были. 2k8r2 надо полагать. Хотя я лично знаю людей, которые пускают серверные ворклоады на клиентский SKU (а в Win7 тот же IIS включен в поставку — почему бы и не использовать :-) )
Можно шаманить и над образом. Честно говоря мне такое в голову не приходило :-)
Но как по мне — эта статья просто демонстрация процесса оптимизации, по сути же ускорение загрузки на минуту или даже на две — как по мне баловство
Event-ы собираются и сбрасываются в файл в ядре. Если не залогинится под пользователем, инициировавшим сессии, то трейс просто не остановится и забьет диск, потому как xbootmgr ставит в автозагрузку отключалку трейса.
Сбор трейсов можно производить и искаропочным logman (и даже гуевым PerfMon-ом), а вот анализом должны заниматься специально обученные индусы, так что SDK — самое место для такого рода утилит.
Task manager вообще говоря — довольно обманчивый инструмент. Чтоб правильно интерпретировать то, что там написано надо довольно серьезно разбираться в потрохах винды :-)
Его надо вообще выкинуть из поставки (тем, кому надо — скачают Process Explorer, а остальным он только вредит :-) )
Что же до торрента. Попробуйте понизить uTorrent-у приоритет. Насколько я понимаю, это должно привести к снижению I/O приоритета и соответственно кеширование будет происходит на более низкие уровни. Но вообще понижением приоритета должны заниматься авторы uT
Отвечу картинкой.
Вот так выглядит процесс загрузки (в первые 20 секунд диск занят на 100%). При подобном дисбалансе CPU/Disk скорость только увеличивается. И за счет того, что надо попросту меньше читать, и за счет того, что при меньшем количестве чтений уменьшается и contention — соответственно меньше disk seek-ов.
Не замечал подобного ни в висте ни в 7. И да, суперфетч здесь в любом случае ни при чем. Однократное копирование какого нибудь файла ему что слону дробина
Ну дык, это работа кеша. В ваших лучших интересах иметь забитый standby list и иметь минимум free list-а. Standby — это все та же свободная память, но ХОТЬ С КАКИМИ ТО данными, а вот free list — это просто потраченная впустую память.
У Соломона/Ионеску в пятом издании более менее подробно расписывается. Возможностей настройки нет. Это чисто внутренний механизм, не предполагающий вмешательство пользователя.
И да и нет. Для SSD отсутствует пенальти на disk seek (поэтому укладывать файлы плотно друг к другу не надо), с другой стороны SSD читает блоками что то около 256К, и желательно чтоб данные в каждом блоке были более менее взаимосвязаны (лучше всего — относились к одному файлу). Сжатие вряд ли поможет атому.
Вообще говоря, ETW появился в XP. С висты ему приделали xml манифесты (вместо mof) и назвали это Crimson. Другое дело, что в икспишечке и близко нет тех шести с чем то сотен провайдеров, которые есть на семерке. Ну, еще один повод для апгрейда :-)
Почему то я уверен, что суперфетч этого не делает. В любом случае, теперь Вы знаете о «сверхсекретном» инструменте, позволяющем посмотреть кто именно загружает файлы в память.
Насколько я знаю, он и не пытается. Кеширует файлы файловая система на пару с кеш менеджером и делает это независимо от любых суперфетчей. Суперфетч же префетчит файлы исходя из истории Вашей активности. Причем разбивает сутки на 4 интервала и каким то хитрым образом использует цепи Маркова для предсказания Ваших последующих шагов. К примеру, если Вы с утра пришли на работу и запустили браузер (ну кто ж сразу к работе приступает то), значит минут через 40 дойдет очередь и до почты и ее надо бы подгрузить в память заранее (собственно это и называется PRE-fetch).
Фильмы, которые открываются с sequential only то ли вообще не кешируются то ли кешируются на Stanby list 0, что значит их выкинут при первой же необходимости. С торрентами сложнее, но я честно говоря не понимаю, почему не выставить низкий I/O приоритет потоку, а вместо этого задрачивать файл постоянными переоткрытиями.
Спасибо, наверное надо где нибудь расписать чего люди теряют при выключении SysMain. В данной статье упоминается создание бутплана для ReadyBoot-а и создание layout.ini для дефрагментатора. Уже одного этого достаточно чтоб даже не приближаться к нему. Там еще ReadyBoost (который в принципе неплох как раз для слабого железа), ReadyDrive (достаточно редкие пока что гибридные накопители) и собственно суперфетч, который таки весьма неглупая штука.
Да я тоже. Диск 5400 выдает во мне пользователя ноутбука. А перегружать ноут, когда можно просто хлопнуть крышкой — это сильно на любителя (хотя надо сказать еще до ноутов я пользовался hibernate-ом на постоянной основе)
Не уверен, но можно заглянуть еще в %SystemRoot%\diagnostics — там лежат PowerShell скрипты, которые занимаются диагностикой. Вообще WDI — достаточно закрытая штука (no user serviceable parts, ага). Так что как там все конкретно устроено — я не знаю.
Имейте в виду, что «compact /c» лично у меня занял 3 часа, так что надеяться на «сейчас быстренько ускорюсь и продолжу заниматься своими делами» не стоит :-)
Лучше оставить на ночь. Причем можно запустить сжатие параллельно в трех окнах
Этим занимается WDI (Windows Diagnostic Infrastructure). Запускается скорее всего либо из сервиса либо из службы, но на самом деле это не нужно, окна они показывают на основании анализа файла %SystemRoot%\System32\wdi\LogFiles\BootCKCL.etl () который собирается при каждой загрузке и содержит (среди прочего) информацию о запуске процессов, о загруженности диска и процессоров. Это такой же ETW Log (.etl), как и те, что собирались автологгером и его можно просматривать xperfview-ом
Выигрыш от сжатия сильно зависит от того, насколько процессор быстрее накопителя. Хотя с другой стороны, я не видел, когда бы это ухудшало ситуацию — иногда просто не сильно улучшает. С другой стороны, место на диске экономится
Вот здесь в частности видно, как на 45-й миллисекунде загружается этот самый winload.exe (то есть event-ы идут начиная с бутсектора, а не winload)
На самом деле это, пожалуй, все что можно получить из преядерного трейса — они ничего не знают ни о настройках ни даже о файлах — складывают в память все чего есть и потом передают ядру в составе loader_block (или как бишь он там называется)
Но как по мне — эта статья просто демонстрация процесса оптимизации, по сути же ускорение загрузки на минуту или даже на две — как по мне баловство
Его надо вообще выкинуть из поставки (тем, кому надо — скачают Process Explorer, а остальным он только вредит :-) )
Что же до торрента. Попробуйте понизить uTorrent-у приоритет. Насколько я понимаю, это должно привести к снижению I/O приоритета и соответственно кеширование будет происходит на более низкие уровни. Но вообще понижением приоритета должны заниматься авторы uT
Вот так выглядит процесс загрузки (в первые 20 секунд диск занят на 100%). При подобном дисбалансе CPU/Disk скорость только увеличивается. И за счет того, что надо попросту меньше читать, и за счет того, что при меньшем количестве чтений уменьшается и contention — соответственно меньше disk seek-ов.
Фильмы, которые открываются с sequential only то ли вообще не кешируются то ли кешируются на Stanby list 0, что значит их выкинут при первой же необходимости. С торрентами сложнее, но я честно говоря не понимаю, почему не выставить низкий I/O приоритет потоку, а вместо этого задрачивать файл постоянными переоткрытиями.
Лучше оставить на ночь. Причем можно запустить сжатие параллельно в трех окнах