А она у Вас до этого загружалась?
Дефрагментация — стандартный maintenance процедура и по идее должна выполняться раз в неделю по расписанию. К сожалению дампы при создаются первым user mode процессом (smss) и их может просто не оказаться, если до него дело не доходит. Попробуйте загрузиться в safe mode (если выйдет — smss создаст дамп) и вышлите мне в личку минидамп. %SystemRoot%\Minidumps — они там по датам проименованы
Память остается свободной. Кеш менеджер использует Working Set процесса System для меппинга файлов (кеш в винде работает через мемори меппинг). Так же как и все остальные Working Set-ы, при необходимости его протриммят. А приоритет нужен для того, чтоб кеширование раздаваемых файлов не «выдавливало» из памяти более необходимые файлы.
ОЗУ никто не «жрет». Оно используется для кеширования. Если ничего более подходящего нет — будут закешированы раздаваемые файлы. Проблемы начинаются когда из кеша начинают выталкиваться нормальные файлы (например экзешники) и за ними приходится каждый раз лазить на диск. По поводу разрастания System Working Set — не беспокойтесь. При первой же необходимости его подрежут
Ну не холивара ради, можно и MSDOS-ом сравнить, который на современных системах грузится за секунду. Это не попытка показать превосходство над жалкими остальными, это попытка ответить на вопрос, как нужно подходит к оптимизации производительности. Ничего подобного xperf/ETW в Linux нет.
Кстати, bootchart работает совсем не так как xperf. Во первых трейс начинается с запуском первого user mode процесса, во вторых это sampled профайлер, в отличие от instrumented (с возможностью снятия семплов, о чем попробую написать позже) в случае xperf
На завершение работы влияют слабо. В основном там имеют значение драйвера и сервисы, не желающие помирать. Для ускорения процесса перезагрузки нужно проводить подобные же мероприятия, но направленные на вылов таких драйверов.
Вытаскивать из группы можно переименованием значения Group в ключе HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MsMpSvc
О, так даже лучше. Но я не про приоритет CPU, который ставится KeSetPriorityThread, я про Win32 «классы приоритетов», которые по хитрым правилам отображаются в приоритеты CPU/Memory/IO для потоков.
Про IFEO IoPriority не знал — большое спасибо. Это более правильный способ «ремонта» uT.
1. Сбрасывается не вся память, а только используемая (та что находится в Working Set-ах) — можно посмотреть на пустой Standby List после каждого hibernate-а.
2. При записи, hiberfil пакуется хитрым алгоритмом, специально предназначенным для скоростной упаковки/распаковки, но имеющим относительно низкий коэффициент сжатия.
Как уже написали, отключение дисплея есть на всех современных ноутах. Да и перенастройка реакции на закрытую крышку занимает от силы секунд 20. Если «оставлять на ночь» — это скорее правило, чем исключение, то да, лучше не реагировать на крышку вообще. Если же это делается раз в пятилетку — то удобнее «хлопать крышкой»
Ну это да. Очень хорошая демонстрация процесса. Но в реальной жизни мы выигрываем минуты, а не проценты :-)
И если перегружаться только при апдейтах, процесс оптимизации загрузки превращается в такую увлекательную игру для ума, не имеющего никакого отношения, собственно, к реальности
«Не держите его так» :-)
Hibernate FTW, серьезно. Помимо ускорения, собственно, загрузки у Вас будут загружены все приложения, открыты документы и пр…
Перегружаться стоит только тогда, когда не перегружаться нельзя (апдейты, например)
Первый наверное можно грузить секунд за 30, а вот второй мне самому интересно :-)
Скорость загрузки увеличивается. Единственное нужно учитывать, что файлы, у которых производится частая запись в средину (базы данных, реестр и пр) начнут сильно фрагментироваться из-за того, что новые данные не обязательно будут помещаться в то же место, в которое помещались старые. Их лучше сразу распаковать (винда сама распаковывает файлы хайвов)
Дефрагментация — стандартный maintenance процедура и по идее должна выполняться раз в неделю по расписанию. К сожалению дампы при создаются первым user mode процессом (smss) и их может просто не оказаться, если до него дело не доходит. Попробуйте загрузиться в safe mode (если выйдет — smss создаст дамп) и вышлите мне в личку минидамп. %SystemRoot%\Minidumps — они там по датам проименованы
www.newegg.com/Product/Product.aspx?Item=N82E16834115830
i7 720QM / 2.5" 5400 rpm HDD
Остальное в данном случае не так уж и важно
— Почему кошки лижут свои гениталии?
— Потому что МОГУТ.
Я же как раз о том, что даже при наличии 8 гиг памяти своп файл держать полезно
Отключали «ненужные» сервисы до этого?
Попробуйте сделать
xperf -on BASE+CSWITCH
чего нибудь здесь поделайте
xperf -d trace.etl
Просто чтоб посмотреть а логгеры вообще включаются
Вытаскивать из группы можно переименованием значения Group в ключе HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MsMpSvc
Про IFEO IoPriority не знал — большое спасибо. Это более правильный способ «ремонта» uT.
2. При записи, hiberfil пакуется хитрым алгоритмом, специально предназначенным для скоростной упаковки/распаковки, но имеющим относительно низкий коэффициент сжатия.
И если перегружаться только при апдейтах, процесс оптимизации загрузки превращается в такую увлекательную игру для ума, не имеющего никакого отношения, собственно, к реальности
Hibernate FTW, серьезно. Помимо ускорения, собственно, загрузки у Вас будут загружены все приложения, открыты документы и пр…
Перегружаться стоит только тогда, когда не перегружаться нельзя (апдейты, например)
Скорость загрузки увеличивается. Единственное нужно учитывать, что файлы, у которых производится частая запись в средину (базы данных, реестр и пр) начнут сильно фрагментироваться из-за того, что новые данные не обязательно будут помещаться в то же место, в которое помещались старые. Их лучше сразу распаковать (винда сама распаковывает файлы хайвов)