xbootmgr -trace hibernate
Можно к base+cswitch добавить еще drivers или latency. В общем чаще всего это кто-то один, максимум — двое. Найти и либо прибить либо разобраться чего им надо
Ну да, я там выше сказал, что bootchart позволяет увидеть общую картину, но он sampling и не особо расширяем. В xperf можно отследить приход конкретного прерывания, найти DPC, связанную с этим прерыванием и отследить завершение конкретного IRP, следующее после этого.
Все сторонние дефрагментаторы сейчас (уже лет 10 как минимум) используют стандартное Defrag API — можно иметь сколько угодно операций перемещения кластеров. Можно даже запустить несколько дефрагментаторов одновременно
Таскать работающий ноут опасно (если он не ssd, конечно) — незапаркованные винты значительно менее устойчивы к физическим нагрузкам, чем запаркованные. Но вообще — дело вкуса, да.
Советы общие: Solomon/Ionescu/Russinovich «Windows Internals», MSDN, помогает чтение исходников: WRK, утекшие w2k/nt4. Когда более менее понятно чем живет и как работает винда в принципе, можно пытаться ковырять всякие частности. Здесь уже нет единого источника: blogs@msdn, собственные эксперименты, перепрочитывание документации в поисках каких то намеков и пр…
Сделал на ThinkPad T500, занято те же полтора гига.
Вот там где сплошная линия — процессоры уже на HIGH_LEVEL занимаются сбросом и чтением (в данном случае где то 25 секунд каждый). Если эта стадия занимает больше всего времени — посмотрите насколько фрагментирован файл hiberfil.sys, померяйте скорость линейного чтения и пр… Если же есть большие задержки до этого — просто смотрите кто это там держит систему.
Навскидку что то не так.
xbootmgr умеет трейсить процесс засыпания (-trace hibernate). Попробуйте включить — может чего нибудь прояснится.
Я на днях посмотрю какую информацию он вообще выдает в этом режиме — никогда до этого не заглядывал.
Ускорять там к сожалению практически нечего. Вся используемая память пакуется и сбрасывается на диск. Причем hiberfil обычно нефрагментирован. Собственно ответом здесь будет использовать меньше памяти или иметь более быстрый диск :-)
Есть еще гибридный сон. Все сбрасывается в hiberfil, но система не выключает питание («Спящий режим»), а уходит в стендбай («Ждущий режим»). Если питание не пропадало — просыпаемся мгновенно, если пропадало (или системе показалось, что смысла ждать уже нет и можно поспать) — восстанавливаемся из хибернейта. Best of two worlds
Если предлагает, значит юзермод уже загружен. Посмотрите есть ли в каталоге Windows свежие минидампы (либо один большой \Windows\memory.dmp). Если есть — можно разобраться кто падает и может даже узнать почему.
Там ниже показано как понизить I/O приоритет. Чтобы посмотреть как IoPriority влияет на работу системы, запустите штатный онлайн дефрагментатор и поработайте. 100% загрузка диска практически не сказывается на отзывчивости системы. Дело не в кешировании как таковом, а в том, что авторы uTorrent-а не удосужились сообщить системе, что данный ввод/вывод менее важен, чем все остальные клевые штуки, происходящие в системе
Собственно она уже есть. Большая часть оптимизации сводилась к перезагрузкам и обучению ReadyBoot/Defrag
Долгий старт сервисов — здесь трудно что либо сделать ибо заранее точно не известно (в том смысле, что решение должно быть принято автоматически и быстро), как повлияет на работу системы отложенный старт того или иного сервиса.
Можно к base+cswitch добавить еще drivers или latency. В общем чаще всего это кто-то один, максимум — двое. Найти и либо прибить либо разобраться чего им надо
sc config msmpsvc group= dummy
конечно же
sc msmpsvc config group= dummy
(пробел после '=' обязателен)
Хорошее эссе про подобные изыскания.
Ну это я немного раскатал губу. На самом деле это был W500
Вот там где сплошная линия — процессоры уже на HIGH_LEVEL занимаются сбросом и чтением (в данном случае где то 25 секунд каждый). Если эта стадия занимает больше всего времени — посмотрите насколько фрагментирован файл hiberfil.sys, померяйте скорость линейного чтения и пр… Если же есть большие задержки до этого — просто смотрите кто это там держит систему.
xbootmgr умеет трейсить процесс засыпания (-trace hibernate). Попробуйте включить — может чего нибудь прояснится.
Я на днях посмотрю какую информацию он вообще выдает в этом режиме — никогда до этого не заглядывал.
Есть еще гибридный сон. Все сбрасывается в hiberfil, но система не выключает питание («Спящий режим»), а уходит в стендбай («Ждущий режим»). Если питание не пропадало — просыпаемся мгновенно, если пропадало (или системе показалось, что смысла ждать уже нет и можно поспать) — восстанавливаемся из хибернейта. Best of two worlds
Долгий старт сервисов — здесь трудно что либо сделать ибо заранее точно не известно (в том смысле, что решение должно быть принято автоматически и быстро), как повлияет на работу системы отложенный старт того или иного сервиса.