Многие пользуются сторонними дефрагментаторами, полагая, что они более эффективны, чем встроенный. Но одно дело предполагать, а другое – знать наверняка. Я приглашаю вас принять участие в эксперименте по сравнению дефрагментаторов!
Производительность системы, установленной на HDD, увеличивается за счет оптимального размещения фрагментов файлов на диске. К сожалению, очень трудно оценить реальный выигрыш в быстродействии от использования того или иного дефрагментатора. Но есть один аспект работы системы, который можно измерить абсолютно точно – скорость загрузки системы!
Что будем сравнивать
В конце книги об ускорении загрузки я обещал сравнить дефрагментаторы, и вот время настало. Однако эксперимент невозможен без вашей помощи!
Тому есть несколько причин:
- интересно сравнить несколько сторонних программ со встроенной утилитой
- эксперимент нужно проводить на физической машине, а не на виртуальной
- для оптимального размещения данных программа должна поработать какое-то время в вашей системе
- любопытно увидеть работу дефрагментаторов на различных конфигурациях, а не только на стендовой
Последний пункт, казалось бы, противоречит смыслу сравнительных тестов, которые всегда проводятся на одной конфигурации. Но мы и не будем сравнивать все средства между собой.
Задача состоит в том, чтобы определить, как оптимизирует загрузку вашей системы выбранная вами программа по сравнению со встроенным дефрагментатором Windows.
Приняв участие в эксперименте, вы точно узнаете, что больше подходит вам. Наблюдателям останется лишь мотать на ус результаты читателей блога. Конечно, так мы сможем проверить только один аспект работы дефрагментаторов. Но даже это даст пищу для размышлений!
Как будем сравнивать
Я составил методику сравнения, которое проводится в два этапа. Сначала для сторонней программы, а потом для встроенной утилиты выполняется:
- Создание отчета WPT для анализа ReadyBoot.
- Измерение времени загрузки с помощью моего пакета CheckBootSpeed.
Я максимально автоматизировал все действия. Лабораторная работа рассчитана примерно на 30-40 минут вашего времени плюс 2-3 часа системного времени, в зависимости от вашего дефрагментатора и размера системного раздела. Можно тестировать в разные дни и даже гулять в парке, пока программы работают.
Скачайте методику в формате PDF (480 кб) и решите, интересно ли это вам.
Если у вас есть замечания или пожелания по методике, я буду рад в течение ближайших трех дней услышать ваши взвешенные мнения в комментариях.
Кто может принять участие в эксперименте
Участвовать может любой читатель блога, но, как и в любой игре, есть системные требования.
- На компьютере установлена Windows 7.
- Сторонний дефрагментатор установлен не менее двух недель назад, причем очень желательно наличие последней версии. Вы в любом случае узнаете, что лучше для вас, но старая версия даст хороший повод критикам дискредитировать ваши результаты.
- В течение последних двух недель не выполнялась ручная дефрагментация загрузочных файлов встроенной утилитой. Это гарантирует, что фрагменты оптимально размещены с точки зрения сторонней программы.
Два последних пункта нацелены на то, чтобы отсечь ситуации, в которых сторонней программе что-то может помешать эффективно выполнить свою работу.
В принципе, встроенный дефрагментатор Windows будет находиться в очень жестких рамках, поскольку у него будет только один шанс оптимизировать загрузку.
По сути, эксперимент сводится к запуску нескольких командных файлов, но требуется внимательность и определенный уровень технической подготовки. Я рассчитываю, что у вас все это есть.
Как принять участие
Достаточно подготовить все необходимые файлы и не позднее 10 января 2012 года отправить их с помощью формы для обратной связи.
Дата выбрана не случайно. Поскольку на носу Новый Год, я полагаю, что у вас есть более приятные хлопоты, чем возня с дефрагментаторами. Однако праздновать 10 дней подряд весьма непросто, и в какой-то день нужно отдохнуть от бесконечного употребления еды и напитков :) Возможно, именно в этот момент вам захочется провести эксперимент.
Ах да, чуть не забыл :) Среди участников эксперимента, прошедших путь до конца и явлющихся подписчиками блога, случайным образом будет разыграна подписка TechNet или MSDN!
Я согласен что стабильность снижена, много форумов перелазил, но большинство вариантов мне непомогло, а некоторые вообще не по теме были.
На данный момент меня ОС пока устраивает, но в дальнейшем или эту ОС выправлю либо буду перезаливать.
Увы, практика показывает, что даже предоставление 30% свободного места не улучшает ситуацию.
И (лицензированный Майкрософтом) дефрагментатор в Windows XP / Windows Server 2003, и «родной» в Windows 7 / Windows Server 2008 — при такой нагрузке бесполезны, поскольку встают колом.
Вот предложение локального Citlink:
Жесткий диск INTEL 320 Series SSDSA2CW160G3K5, 160Гб, SSD, SATA II
9650 руб.
А вот это зря. Нужно пользоваться постоянно, и после каждой такой процедуры перезагрузите комп раз 5 с промежутком в минуты 2-3. Очень удивитесь результату.
Встроенный, но он меня не устраивает :(
а сторонними не так и хочется пользоваться, оставляя расписание в строенном, оставляю все как есть…
В принципе, я ожидал, что приглашение к изучению одного аспекта работы дефрагов вызовет общую дискуссию, но не думал, что откроется ящик Пандоры :)
Vladislav Artukov, у вас хороший вкус к SSD. Но я предпочитаю синицу в руках, а не журавля в небе через два года. Мой диск был куплен в США всего за $150.
Что касается вашего теста. Ок, вы доказали мне, что на вашей серверной ОС встроенный дефраг непригоден.
Добавлено позже. Мне лишь непонятно, почему у вас успешно справляется с задачей MyDefrag, использующий тот же API, что и дефраг Windows. Возможно, стоит все-таки пнуть родной дефраг посильнее?
Антон, это беспредметный разговор. Предметный нужно вести в форуме.
Игорь, делать это необязательно, ибо система сама это делает, о чем я писал в блоге и книге.
И если вы заглянете в методику теста, то увидите там ту же тему :)
Oleg, если вас не устраивает встроенный, вы должны как-то сформулировать свое недовольство, но я этого не вижу.
WindowsNT.LV, я не думаю, что указанная статья KB применима к 7. Там другой дефраг, да и механизм теневого копирования работает иначе.
Я не знаю, с какой частотой создаются теневые копии в 7 — это нигде не задокументировано. Но я уверен, что это привязано к заданию планировщика SR (см. под картинкой).
Создание точек восстановления объединено с теневыми копиями в 7.
Важно для тех, кто уже скачал архив с командными файлами для эксперимента в первые два дня!
В файле 1-trace-your-defrag.cmd необходимо в последней строке исправить WinDefrag на YourDefrag. Вы можете сделать это вручную или скачать набор файлов заново по той же ссылке.
Спасибо Алексею за информацию.
Дело в том Vadim Sterkin, что там показывают проценты, анализа и дефрагментации.. но они стабильны на взгляд и не видно, идет ли там какая либо дефрагментация или нет, другое дело в XP sp3, все четко и ясно, видно что дефрагментировано а что нет…
Разок подвинет.
Именно в этом была проблема.
Как вариант- можно было выделить отдельный раздел под бекапы, заодно и сэкономить чуть- чуть места, выделив размер кластера в 64 КБ. В отдельном разделе , где хранятся только бекапы, фрагментироваться нечему. Это бы позволило избежать лишнего копирования.
Выделять достаточный объём диску. По умолчанию система резервирует вроде 15% под MFT, а когда свободного места становится меньше 15%, начинает писать туда. При том алгоритм выделения явно не сильно хороший, и получается как у WindowsNT.LV— десятки тысяч фрагментов. А так как встроенный дефрагментатор отказывается работать при меньше чем 15% свободного места, фрагментация только растёт до ужасающих величин.
Обязательно будем говорить об этом и очень скоро :) Только я не планировал затрагивать вопросы фрагментации MFT.
Какая система? Источник информации?
В XP было 12.5% (пруф по ссылке). По Windows 7 информации конкретной нет, но можно опираться на Vista, следуя KB961095.
Там очень плохо написано с точки зрения понятности изложения — статьи rapid publishing публикует поддержка и зачастую напрямую со слов разработчиков. Это делает русский вариант криво-машинного перевода совсем невозможным для восприятия. Зато появляется тайное знание, которое в MSDN попадает не всегда :)
Вкратце, изначально для MFT используются область в 200 Мб. Если нужно больше места под MFT, создается следующая зона такого размера и т.д.
И раз уж зашла речь об MFT, то нередко способность дефрагментировать ее выдается за великое преимущество сторонних дефрагов. Штатный дефрагментатор Windows ее молча обрабатывает, опять же со времен Vista, о чем есть скромная строчка в KB942092.
Oleg, я понял вас. Если у меня будет возможность пообщаться с продуктовой группой, я обязательно сообщу им о важности квадратиков для конечных пользователей.
Ага, запамятовал. Не зря приписал «вроде».
Vadim Sterkin,
А нет никакой особой методики, поскольку мерялся не получаемый прирост скорости (ну, разве что по ощущениям юзеров и визуальной/слуховой работе диска), а сам факт отсутствия или наличия фрагментации, просто появилась тема, разрослась до десятка страниц и уже начались повторы, посему была предложена идея сравнить разные программы, кому не лень. В итоге имеем то что имеем. Многие были удивлены, что штатный дефрагментатор, при всех его недостатках оказался так хорош.
WindowsNT.LV,
я в курсе, спасибо ;)
дополню по поводу теневых копий:
да, при несовместимом дефрагментировании сторонние дефрагментаторы убьют их (и убивают ведь), но при использовании виндового дефраг-API эта проблема легко решаема (но иногда про неё забывают), либо переписыванием программерами «своего» драйвера
если вспомнить о том как происходит запись на диск, то выльется довольно простое решение:
Итак, как же происходит запись, в большинстве книжек/статей, во всяком случае раньше, писали примерно так -«записывается файл, бла-бла-бла, затем следующий, бла-бла-бла, затем удаляется первый и на его место уже можно записать другой…» очень расплывчато и верно только в сути :)
На самом же деле, все немного проще (или сложнее, но это кому как):
Имеем диск, допустим на 100 кластеров, имеем несколько файлов.
Записываем первый файл, занявший 6 кластеров , затем еще один = 9, еще = 7, еще = 5, еще = 3,5, но занимает все-равно 4 (не забываем про реальные файлы которые редко занимают ровное количество кластеров? тему потерянных кластеров не буду обсуждать пока), получаемая картина — |++++++|+++++++++|+++++++|+++++|++++| — свободна куча места.
Продолжая писать на пустой диск мы постепенно можем занять это место, файлы будут идти подряд и не будут фрагментированы, все здорово. Но самое интересное (как кажется многим) начинается, когда нам больше не нужен один из файлов уже лежащий на диске, пусть будет второй (самый большой). Рисуем следующую картину — |++++++|———|+++++++|+++++|++++|.
Теперь мы захотели записать новый файл, размером 8, да он спокойно влезет в освободившееся пространство, но он будет записан не туда, куда многие подумали, картина станет следующей — |++++++|———|+++++++|+++++|++++|++++++++|…
Таким образом работают ОС и ФС, они сами предотвращают фрагментацию (о чем не спорил только ленивый). Но теперь новая картина? а что будет если мы сотрем последний файл? |++++++|———|+++++++|+++++|++++|———|.
Многие считают (пишут), что на освободившееся место будут писаться файлы, а вот «фигвам», следующий файл, размером = 4 будет записан после уже освободившегося пространства — |++++++|———|+++++++|+++++|++++|———|++++| и так происходит до конца пустого места. И только после того как «счетчик дойдет до 100, или в случае когда оставшегося места не хватает для записи файла целиком (здесь тоже есть свои ограничения на выделяемый размер для записи целого файла, но не буду их касаться), запись начнется в свободные «пустоты».
Зачастую, особенно много про это говорили на 2k и ХП, многие использовали разные твики для того чтоб (якобы) снизить фрагментацию и писать в пустое место, но, на самом деле, опять же зачастую, это только усугубляло ситуацию (так же помню про твик с поиском минимального непрерывного пространства для записи файла целиком, который помогал, но тоже не всегда, так как был несколько однобок).
Уффф… если чо, жду дополнения и комментарии и все-такое :)
Конечно это интересно…. Но ИМХО большой разницы между дефрагментаторами нет… исключая RAID массивы, а вот это было бы интереснее…
ЁжЫГ, непонятно, что использовать в качестве бенчмарка для наличия/отсутствия фрагментации. Каждая лягушка свое болото хвалит.
Дмитрий, я уверяю вас, что в исследуемом аспекте может быть большая разница между дефрагами. И первые результаты участников эксперимента это подтверждают ;)
Увеличить рисунок
Я не буду вдаваться в подробности, но это результат разных дефрагов на одной машине.
Если вам интересна тема RAID, разработайте методику и предложите ее… там, где достаточное кол-во читателей использует RAID :)
Вспомнилось тут, как борются с фрагментацией во «вконтактике» просто не удаляют ничего :)
Штатный дефрагментатор был таким «бенчмарком», с его мнением были согласны все попробованные в той теме дефрагментаторы.
А почему подписи на английском?
ЁжЫГ, понятно. Но если со штатным согласны все сторонние, то зачем они нужны? :))
Виталий, потому что у WPT английский интерфейс. В данном случае подписи вообще не имеют значения, достаточно цветовой гаммы :)
Vadim Sterkin,
вот потому, в той теме (на нашем форуме) и пришли мнению, что по качеству работы штатный дефрагментатор лучший (хотя такие же результаты показал не только он) ;)
Мне будет очень любопытно узнать — какой же дефрагментатор для Windows 7 окажется эффективнее. Буду следить за новостями :)
Сам же пока сижу на ХР. Пользуюсь Raxco PerfectDisk. Автоматом каждый 3 дня поддерживает системный диск. Про встроеный в ХР я даже не в курсе — может ли он работать по расписанию.
Хотя однажды PerfectDisk учудил — после onboot дефрагментации пришлось делать chkdsk — т.к. все файлы стали абракодаброй — помогло, но ОС пришлось ставить заново. Неприятный момент конечно.
За последнее время перепробывал всякие дефрагментаторы от mydefrag до суперпродвинутого diskeeper с его интеллектуальной записью…..в конечном итоге купил ssd…..а оставшийся диск не системный отдал на попечение встроенному дефрагу в win 7…
Вот так вот
Из личного опыта
Как не странно но ваш блог читают не только те кто пользуется виндовз — в опросе не хватает одного пункта :)
Кстати спасибо за статью.
Djalin, oпрос составлен правильно, речь о Windows, что ясно из методики хотя бы.
А что вызывает у вас интерес в моем блоге, если вы не пользуетесь Windows? Покатушки? :)
evdpavel, да, сто лет назад мне что-то не помогло на другой ОС, и в новой я уже не буду этим пользоваться. Читаю об этом регулярно :)
А между тем, из 50 «участников» результаты прислали только двое. Наверное, остальные 48 и вправду отложили на 2012. На них и возложим вину за провал эксперимента :)
Добавил в пост информацию собранную на Windows 7 x64.
evdpavel, сторонний дефраг всегда что-то найдет, такая у него задача :) Поздравляю, он переместил 5 квадратиков, победа!
Vadim Sterkin, от куда такая уверенность, если, как Вы говорите, API одинаковые? Вот у меня нет таковой.
«Квадратики всем видны», а вот что сделал штатный в данном случаи не видно: было 0 процентов фрагментации и осталось 0.
Я только привел факты, с которыми лично столкнулся.
Рад, что Вы присудили победу Defraggler-у за 5 квадратиков :)
evdpavel, это вы присудили победу, я лишь выразил ее количественно.
Нельзя оценивать эффективность дефрага по кол-ву квадратиков. И уж тем более нельзя сравнивать сторонний дефраг со встроенным на основе этого.
Ваша логика основана на том, что вы уверены в преимуществе стороннего дефрага. Допустим, я уверен в преимуществе встроенного. Он показывает 0% как до, так и после стороннего. Вывод — сторонний ничего не сделал, а лишь обманывал кол-вом квадратиков.
Для сравнения нужны более объективные методики. Я их не знаю, поэтому и не делаю никаких выводов. Вы их тоже не знаете, но выводы делаете. Такая вот разница между нами.
Один аспект можно проверить, и я озвучил методику в статье. Вы ее не оспорили и никаких результатов не прислали пока. Посему я не вижу смысла продолжать дискуссию. Тем более, мне не хочется портить вам настроение, поднявшееся от победы с разницей в 5 квадратиков :)
Ой.. Я не сравнивал продукты и выводы никакие не делал. Победу никому не присуждал. Я только выполнил определенную последовательность действий, показал результат и … всё.
>> Для сравнения нужны более объективные методики.
Согласен.
>> Я их не знаю, поэтому и не делаю никаких выводов.
В предыдущем абзаце Вы писали:
>> Вывод – сторонний ничего не сделал, а лишь обманывал кол-вом квадратиков.
Получается, что Вы противоречите сами себе.
Для информации: В Defraggler-е можно щелкнуть по любом блоку и посмотреть какие именно файлы, располагаются в нем.
Получается, что вы читаете выборочно и невнимательно. Прочтите абзац целиком и вы увидите иронию, которая подчеркивает изъяны в логике.
И вы лукавите насчет отсутствия выводов в вашем блоге, ибо они вынесены в заголовок записи :)
Дальнейшая дискуссия «ни о чём» не представляет для меня интереса, так что я оставлю последнее слово за вами, если вы захотите им воспользоваться.
Когда-то давным давно пробовал разные дефрагментаторы, уже не помню их названия. Остановился на MyDefrag (тогда JKDefrag). Как мне казалось, именно этот дефрагментатор работал быстрее остальных, перемещал все файлы в начало диска (красиво выглядит ведь) и мне больше всего нравилось представление состояния дефрагментации именно в этой программе.
Сейчас же я использую только встроенный дефрагментатор. И на это есть причины:
1) Он уже есть в системе, не нужно искать и устанавливать сторонний дефранментатор.
2) Нельзя сказать, после работы какого дефрагментатора система работает быстрее — с этой точки зрения вообще нет никакой разницы между дефрагментаторами.
Кстати, для XP x86 и 2003 x86 есть PageDefrag, а вот для x64 и более поздних систем таких инструментов нету. Как быть?
А недавно меня посетили и следующие мысли:
По идее, файлы, которые используются при самой загрузке системы, должны быть размещены подряд (и, хорошо бы, в порядке загрузки). Но какой дефрагментатор предоставит гарантию именно такой работы? Мне кажется, что системный дефрагментатор может об этом заботиться (ну а вдруг?).
И ещё: я думаю, что дефрагментации нет смысла подвергать файлы, не относящиеся непосредственно к работе системы. Из-за фрагментации видеофайла вряд ли он будет проигрываьться с задержками, а вот файлы, необходимые для работы программы, загрузятся в память быстрее, если они дефрагментированы. Так что файлы, с которыми пользователь часто работает, вообще дефрагментировать не стоит: при дефрагментации файлы ведь помещаются подряд, друг за другом. А после редактирования какого-либо файла он уже не помещается в место, куда он попал при дефрагментации (оказался зажат меджу двумя другими файлами), и «куски» этого файла «вылезают» в другое место. Далее происходит дефрагментация, затем снова увеличение файла (ведь редко когда редактируемые файлы теряют размер), и опять дефрагментация. Выходит сизифов труд, да и толку от дефрагментации этих файлов я не вижу — мы ничего не выигрываем. Ну не будет заметна разница при считывании одного файла. Тут какая-то разница может быть при копировании большого количества файлов, и то только при копировании на более скоростной накопитель, чем источник файлов.
Но любой дефрагментатор по умолчанию обрабатывает все файлы на диске.
Есть какие-то дефрагментаторы, позволяющие навести порядок в файлах, находящихся в определённой папке.
Так что я скорее всего подумаю на тему использования именно такого дефрагментатора.
Vadim Sterkin, в моем блоге в теме поста не вывод, а попытка заинтересовать читателей к осмыслению фактов.
Поделюсь своим «секретом» быстрой загрузки win XP (может кому будет интересно :)
1. С помощью BootVis оптимизирую загрузочные файлы
2. Дефрагментирую эти загрузочные файлы дефрагментатором UltimateDefrag (пробовал очень много разных дефрагментаторов именно UltimateDefrag дефрагментирует загрузочные файлы (и не только) лучше всех)
Результат, win XP с восьмью небольшими прогами в автозагрузке, включая антивирус Касперского, грузится за 16 сек.
HDD обычный 7200 об. SATA2
Пользователям хрюши, рекомендую.
К сожалению как на win7 UltimateDefrag не знаю, так как не пользуюсь семеркой, знаю только что поддерживает win7, ну а BootVis только для XP.
http://ompldr.org/vYzAycA/Безымянный.JPG