про дефрагментацию на SSD дисках

  • Mikl777
  • 18.07.2020, 00:12
  • Просмотров: 382
вот уже 2 человека ко мне обратилось за этот месяц
с вопросом ПОЧЕМУ тормозит комп, прикол в том что у обоих были ссд
при чём ссд НЕПЛОХИЕ, у обоих были MLC SATA SSD Samsung
у одного 512 гб оем 840pro
у второго ретейл 840pro

и что же я у обоих обнаружил? что уровенть ФРАГМЕНТИРОВАННОСТИ файловой системы был более 60% !

ну и оба ссд работали вообще без юзерской области OP, что давало фактическое х5 усиление записи ( на каждый 1 ГБ записанных в ссд данных - внутри ссд в нанд фактически записывалось 5 ГБ) что дополнительно замедляло дисковую подсистему.

в итоге я обоим поставил O&O Defrag, показал им, как им именно ДЕФРАГМЕНТИРОВАТЬ ссд (O&O Defrag при этом ж честно предупреждает что результатом дефрагментации - будет повышенный износ на ссд как результат это опарации), + обоим сделал области OP по 50 ГБ в хвосте диска
и у обоих "пациэнтов" всё прошло, и компы снова заработали как новенькие!
Обсуждение закрыто модератором
на ssd франментация пофиг. нужо применять trim
я тоже так думал! но вот реально 2 клиента приплыло
с настолько жуткой фрагментацией что прямо было видно что медленнее шеволится.
особенно это было заметно по работе с большой почтовой базой TheBat
после указанных выше операций - 50ГБ база стала грузиться "существенно" быстрее (засекали секундомером!)
Это немного странно.

Не занятая область это в любом случае полезно.
Но по поводу дефрагментации я не уверен.
Для SSD нет потерь времни на позиционирование головок. Возможны тонкости с размерами сектора. Но я не понимаю как такие эффекты могу дать разницу в производительности видимую пользователю, тем более на десктопах и низкая интенсивность обращений к диску, и низкая доля записи обычно.
Не понимаю почему такой результат.
вообще как раз в поиске рандомных файлов у ссд производительность жалкие 45 мб/сек
ну так, для справки.
поэтому файл фрагментированный на 15 фрагментов - скорость его чтения получается "рваной" при поиске каждого нового фрагмента файла она падает, потом срабатывает конвейеризация и этот фрагмент считывается быстро (со скоростью порядка 450 мб/сек), потом снова падает при поиске следующего фрагмента файла.
так что усреднённо скорость да, должна упасть , если файл сильно фрагментирован.
и даже до состояния, что это будет ВИЗУАЛЬНО ощутимо заметно
рандомные 4К файлы, скорость чтения порядка 200. Ты точно выше не про evo писал?
https://versus.com/ru/samsung-840-pro-series-512gb-vs-samsung-860-evo-1tb-msata
быстро рандомные 4К ищутся ТОЛЬКО на оптане там 300 мб/сек, и я в этом лично убеждаюсь ежедневно
как владелец 900P 280 ГБ ))

а все остальные ссд на свете - у сата в среднем 35 мб/с
у NVMe "лучших из лучших" - 65 мб/с (у мощных серверных, гарантирующих латентность - не более 20мс)
я через кристалдискмарк мерял порядка 35 мб/с на 840pro
и на самых лучших ссд быстрее чем 65 мб/с я не видел
у ссд производительность жалкие 45 мб/сек
Это случайное чтение мелкими блоками с низкой глубиной очереди. У десктопа такого режима на практике быть не может. Просто потому что у механики в этом режиме сотни килобайт. Часть компьютеров до сих пор с механическими дисками.

Вангую что рост скорости не результат дефрагментации а результат чего то сопутствующего дефрагментации.
при фрагментации как раз и будет случайное чтение с низкой глубиной очереди )
это как раз этот случай ) и будет.
и он сильно замедляет дисковую систему.
у O&O несколько типов дефрагментации Интересно, какой применялся?
который по умолчанию убивающий фрагментированные файлы и оптимизирующий свободное место чтобы фрагментация при работе диска снова не нарастала
все же мне кажется что просто добавили ОР и пошло А так просто файлы болтались в протухших ячейках...
Польза от O&O видимо тут - что он TRIM-ами закидал контроллер SSD и тот быстро перекинул данные из полудохлых ячеек в свежую OP
протухших ячеек не было на обоих ссд износ ячеек по данным смарта был в пределах 10%
а ссд делает износ равномерным, от этого и было усиление записи (изза отсуствия вменяемой области OP ссд играл в "пятнашки")
Кстати что меня прикололо в HDD WD с SMR Они тоже работают с командой Trim, и имеют OP область, о которой сообщают винде. Правда у меня согласно SSD-Z на таком HDD она всего 88 кб :)
Утилитой Trimcheck показывает, что TRIM там работает, видимо, шинглы постоянно перекладывает
Дожили
а системы сколько видели на этих дисках?

по-идее - только 480, т.е. там 32 гига "заводской" ОР уже должно бы быть?
не на всех дисках есть такая OP у самсунга 512 отформатированы как 512 (но принимая что гигабайт это 1000000000 байт) т.е. под OP выделено жалких 4%
это очень мало. и даёт нехилый Write Amplification
лучше бы trim проверил. Ты его дефрагментацией, которая для ssd не нужна и выполнил вручную
TRIM работал но по факту была сильная фрагментация в расположении кусков файлов.
просто весь диск был полностью красным.
проверил - франментация у меня на 860 pro 80% скорость как была так и осталась

trim автоматом не выплняется - он должен быть в шедулере
у мне раз в неделю

на 970м нвме тож самое

железакам год
"trim автоматом не выполняется"
это на рейдовых дисках?

потому как на обычных мелкософт декларирует автоматическое исполнение?
странно, фрагментация там показывается фиктивная Даже после дефрагментации блоки данных так же в реале фрагментированы.
А что за винда была? Вроде как начиная с 7-ки ssd распознается и руками дефрагментацию делать не нужно?

И почему там ОР не оказалось? Ее разве руками создавать надо? Ладно китай, но для брендов это странно...
7-ка и 2008-й и в обоих случаях трим корректно работал
через тримчек проверял