Сжатие NTFS на SSD - взлеты и падения

В этом разделе обсуждается сжатие NTFS на жестких дисках как метод повышения производительности доступа к диску и делается вывод о том, что оно чаще всего бывает плохим, чем нет. Но я всегда рассматривал сжатие как способ экономии места и узнал об этом. И теперь у меня есть твердотельный накопитель, где пространство дорого, а снижение производительности, например, для чтения / записи 2 кластеров вместо 1, намного меньше.

С другой стороны, поскольку твердотельные накопители намного быстрее жестких, я ожидаю, что более высокая пропускная способность приведет к более высокой загрузке ЦП. Может ли это стать проблемой? Есть еще мысли по этому поводу?

Мне нравится эффект экономии места, он не огромный, но он есть. Однако если производительность вызывает беспокойство, я бы предпочел отключить ее:

Microsoft написала это некоторое время назад в блоге :

NTFS сжимает файлы, разделяя поток данных на CU (это похоже на работу разреженных файлов). Когда содержимое потока создается или изменяется, каждый CU в потоке данных сжимается индивидуально. Если сжатие приводит к уменьшению на один или несколько кластеров, сжатый модуль будет записан на диск в сжатом формате. Затем разреженный диапазон VCN привязывается к концу сжатого диапазона VCN для выравнивания (как показано в примере ниже). Если данные недостаточно сжаты, чтобы уменьшить размер на один кластер, то весь CU записывается на диск в несжатом виде.

Такая конструкция делает произвольный доступ очень быстрым, поскольку необходимо распаковать только один CU для доступа к любому VCN в файле. К сожалению, большой последовательный доступ будет относительно медленным, поскольку декомпрессия многих CU требуется для выполнения последовательных операций (таких как резервное копирование).

И в статье КБ пишет это :

Хотя сжатие файловой системы NTFS может сэкономить дисковое пространство, сжатие данных может отрицательно повлиять на производительность. Сжатие NTFS имеет следующие характеристики производительности. Когда вы копируете или перемещаете сжатый файл NTFS в другую папку, NTFS распаковывает файл, копирует или перемещает файл в новое место, а затем повторно сжимает файл. Это происходит даже тогда, когда файл копируется или перемещается между папками на одном компьютере. Сжатые файлы также расширяются перед копированием по сети, поэтому сжатие NTFS не сохраняет пропускную способность сети.

Поскольку сжатие NTFS требует значительных ресурсов процессора, затраты на производительность более заметны на серверах, которые часто связаны с процессором. Сильно загруженные серверы с большим объемом трафика записи являются плохими кандидатами на сжатие данных. Однако вы можете не испытывать значительного снижения производительности на серверах только для чтения, в основном для чтения или с небольшой нагрузкой.

Если вы запускаете программу, которая использует ведение журнала транзакций и постоянно записывает в базу данных или журнал, сконфигурируйте программу для хранения своих файлов на томе, которое не сжато. Если программа изменяет данные с помощью сопоставленных разделов в сжатом файле, программа может создавать «грязные» страницы быстрее, чем их может записать сопоставленный писатель. Такие программы, как Microsoft Message Queuing (также известная как MSMQ), не работают со сжатием NTFS из-за этой проблемы.

Поскольку домашние папки пользователей и перемещаемые профили используют много операций чтения и записи, Microsoft рекомендует размещать домашние папки пользователей и перемещаемые профили на томе, который не имеет сжатия NTFS, в родительской папке или в корневом каталоге тома.

Резюме:

сжимайте только небольшие файлы, которые никогда не изменяются (только чтение и запись в него не производится), поскольку чтение выполняется быстро, но для записи требуется несжатие и новое сжатие, которое потребляет мощность процессора, а тип хранилища не так важен.

Поскольку Клаудио подробно рассказывает о многих вещах, я собираюсь возобновить его мнение, которое также принадлежит мне, я видел те же самые эффекты после попытки сказать то, что он говорит.

Для SSD не должно использоваться сжатие NTFS.

Теперь я перечислю некоторые мотивы такого утверждения:

Мотив № 1: он убьет SSD быстрее, так как делает две записи; Сжатие NTFS всегда записывает несжатые данные до начала сжатия в ОЗУ, а затем перезаписывает сжатые данные только в том случае, если прирост составляет не менее 4 КБ.

Мотив №2: использование кластера NTFS 4 КБ на твердотельном накопителе приводит к потере 50% скорости твердотельного накопителя, проверьте любой эталонный тест и увидите, что блоки размером 128 КБ делают твердотельный накопитель в два раза быстрее, чем при использовании блоков 4 КБ, а сжатие NTFS можно использовать только в разделах NTFS кластера 4 КБ.

Мотив № 3: Существуют контейнеры (например, PISMO File Mount), которые могут создать контейнер, который выглядит как сжатие и / или шифрование на лету, такие участники выполняют сжатие в ОЗУ и не отправляют несжатые данные на диск перед перезаписью. в сжатой форме, также больше, PISMO получает лучшую степень сжатия, чем NTFS.

Есть намного больше мотивов, но это самые главные импортеры.

Точка otrer - SPEED, любое сжатие выполняется на CPU, поэтому, если у вас нет очень быстрого CPU (для NTFS используется монопоток, в то время как для некоторых контейнеров используется многопоточность), вы увидите очень медленное чтение / запись. при сжатии; в худшем случае, у вас может быть очень быстрый процессор, но если он используется для других целей (например, рендеринга, транскодирования и т. д.), для сжатия не останется процессора, поэтому вы снова получите низкую производительность.

Сжатие NTFS хорошо только для традиционных медленных дисков, когда у вас процессор мало используется, но требует хорошей дефрагментации после каждой записи (на уровне файла), потому что каждый блок 64 КБ (сжатый или нет) записывается с кратностью 64 КБ; единственный способ упаковать такие фрагменты - после сжатия (или записи в сжатую папку) выполнить дефрагментацию такого файла.

П.Д .: Остерегайтесь того, что мы говорим о Windows на реальном оборудовании, а не на виртуальных машинах, важно то, кто пишет на физический носитель, у других могут быть слои кэша, которые могут смягчать эффекты, а также значительно улучшают ситуацию.

Никто не говорит о проблеме мэра на не SSD, это фрагментация.

Каждый блок 64 КБ записывается в том месте, где он был бы без сжатия, но он может быть сжат, поэтому, по крайней мере, он равен <= 60 КБ, а затем записывает менее 64 КБ, а блок битового гнезда будет идти так, как если бы предыдущий не был сжать, так что много пробелов в голове.

Протестируйте его с помощью мультигигабайтного файла машины virtusl любой системы Windows (они, как правило, уменьшаются на 50%, но с огромными> 10000 фрагментами).

А для SSD там что-то не сказано, как, черт возьми, это написать? Я имею в виду, что если он пишет несжатый файл и затем перезаписывает его сжатой версией (для каждого мегаблока по 64 КБ), срок службы SSD сильно сокращается; но если он записывает его непосредственно в сжатой форме, то SSD в реальном времени может быть меньше или короче .... дольше, если вы пишете только 64 КБ сразу, короче, намного короче, если вы записываете 64 КБ в 4 КБ, потому что он будет писать такие 64 КБ (в сжатом виде) столько раз, сколько 64/4 = 16 раз.

Нарушение производительности вызвано тем, что процессорное время, необходимое для сжатия / распаковки, будет больше, чем время, затрачиваемое на запись блоков не по 4 КБ ... так что с очень быстрым ЦП и очень медленным сжатием диска сокращается время записи и чтения, но если SSD очень быстрый и процессор довольно медленный, он будет писать гораздо медленнее.

Когда я говорю о быстром или медленном процессоре, я имею в виду, что в этот момент процессор может использоваться «математикой» или другим процессом, поэтому всегда думайте о свободном процессоре, а не о спецификациях процессора на бумаге, то же самое относится и к диску / SSD, он может использоваться несколькими процессами.

Скажем, у вас есть 7Zip, записывающий огромный файл с другого диска с помощью LZMA2, он будет использовать много ресурсов ЦП, поэтому, если в то же время вы копируете сжатый файл NTFS, у него нет свободного ЦП, поэтому он будет работать медленнее, чем без NTFS. сжатие, но как только 7Zip прекратит использование ЦП, такой ЦП сможет сжимать NTFS быстрее, и в это время сжатие NTFS может делать вещи быстрее.

Лично я никогда не использую сжатие NTFS, я предпочитаю контейнеры PFO для монтирования файлов PISMO (со сжатием, а также позволяет выполнять надписи, как на лету, так и прозрачно для приложений), это дает намного лучший коэффициент сжатия и меньшее влияние на процессор, в то время как это чтение и писать на лету, не нужно распаковывать перед использованием, просто смонтировать и использовать его в режиме чтения и записи.

Поскольку PISMO выполняет сжатие в ОЗУ перед записью на диск, SSD может работать дольше, мои тесты сжатия NTFS заставляют меня думать, что он отправляет данные на диск дважды, сначала без сжатия, и после этого, если он может сжимать, он перезаписывается в сжатом виде ,

Почему скорость записи со сжатым NTFS на моем твердотельном накопителе составляет примерно 1/2 от несжатой с файлами, а не со сжатием почти на 1/2 своего размера или меньших сжатых размеров? В моем AMD Threadripper 2950 (32 ядра и 64 потока) с оперативной памятью 128 ГБ (быстрый ЦП, очень быстрый ЦП) при использовании его менее чем на 1%, поэтому имеется достаточно ЦП для сжатия быстрее, чем максимальная скорость SSD, возможно, потому что Сжатие NTFS начинается после того, как блоки размером 64 КБ отправляются на диск без сжатия, а затем перезаписываются сжатой версией ... о, если я делаю это на виртуальной машине под управлением Linux на хосте и Windows на гостевой, то кэш Linux сообщает мне, что такие кластеры записываются дважды и скорость намного, намного быстрее (Linux кэширует несжатые записи NTFS, отправленные гостевой системой Windows, и, поскольку после этого они перезаписываются сжатыми данными, Linux не отправляет несжатые данные на диск,

Я не рекомендую использовать сжатие NTFS, за исключением того, что в гостях на виртуальных машинах запускаются окна, если хостом является Linux, и никогда, если вы используете процессор как движок, если ваш процессор недостаточно быстр.

Современные SSD имеют огромный внутренний оперативный кэш, так что запись + перезапись, вызванная сжатием NTFS, может быть уменьшена системой внутреннего кэша SSD.

Мои тесты проводились на «симпатичных» SSD без внутренней оперативной памяти для кэширования внутри SSD, когда я повторял их на тестах с оперативной памятью, скорость записи была выше, но не так, как можно было бы подумать.

Проводите свои собственные тесты и используйте файлы огромных размеров (больше, чем общее количество установленных там файлов, чтобы избежать кеширования скрытых результатов).

Кстати, кое-что, что некоторые люди не знают о сжатии NTFS ... любой файл размером 4 КБ или ниже никогда не получит сжатие NTFS, потому что нет способа уменьшить его размер по крайней мере 4 КБ.

Компрессия NTFS занимает блоки 64 КБ, сжимает их, и если она может уменьшить один кластер (4 КБ), то она записывается сжатой, 64 КБ - это 16 блоков по 4 КБ (последовательных).

Если файл размером 8 КБ, когда сжатие заканчивается, окончательный результат больше 4 КБ, он не может сохранить кластер, поэтому он записывается без сжатия, и т. Д. Pression должен получить не менее 4 КБ.

Ах, а для сжатия NTFS NTFS должна иметь размер кластера 4 КБ.

Попробуйте выполнить тест: используйте кластер 128 КБ в NTFS на SSD. Вы увидите значительное улучшение производительности при скорости чтения и записи.

Файловые системы на SSD с кластером 4KiB теряют значительную часть своей скорости, в большинстве случаев теряются более чем на 50% ... посмотрите какие-либо тесты для тестирования с разными размерами блоков, от 512Bytes до 2MiB, большая часть SSD записывает в два раза скорость при размере кластера 64 КБ (или 128 КБ), чем при 4 КБ.

Хотите настоящий стимул для вашего SSD? Не используйте кластер 4 КБ в файловой системе, используйте 128 КБ.

Используйте кластер 4 КБ, только если более 99% ваших файлов меньше 128 КБ.

Etc, etc, etc ... тестируйте, тестируйте и тестируйте свой собственный случай.

Примечание. Создайте системный раздел NTFS с помощью diskpart в режиме консоли при установке Windows с кластером 128 КБ или из другой Windows, но не разрешайте форматирование Windows в графической части установщика (он всегда будет форматировать его как NTFS кластера 4 КБ).

Все мои Windows теперь установлены в NTFS-разделе кластера 128 КБ на SSD> 400 ГБ (SLC).

Надеюсь, все станет ясно, M $ не говорит о том, как iy пишет сжатый NTFS, мои тесты говорят мне, что он пишет дважды (без сжатия 64 КБ, затем <= 60 КБ), а не только один раз (остерегайтесь этого, если на SSD).

Осторожно: Windows пытается сжимать NTFS некоторых внутренних каталогов, независимо от того, говорите ли вы, что NTFS не сжимается, единственный способ избежать этого, если размер кластера NFTS отличается от 4KiB, поскольку сжатие NTFS работает только на разделах NTFS с размером кластера 4KiB.

Я вижу комментарии других, и я думаю, что люди часто забывают самый полезный сценарий, в котором сжатие файлов и папок NTFS имеет большое преимущество на SSD: современные инструменты разработки. В моей установочной папке Matlab (для обычного пользователя только для чтения) в папке для установки установлены следующие объемы данных:

28,5 ГБ данных 30,6 ГБ Размер на диске Содержит 729,246 файлов и 15.000 папок (!!!)

Это на моем ноутбуке с 500 ГБ SSD, где раздел Windows составляет 200 ГБ.

Я знаю, что Matlab немного экстремален в этом отношении, но многие devtools обладают схожими свойствами: тонна небольших, сильно сжимаемых текстовых файлов (заголовки, код, файлы XML). Я сжимаю Matlab прямо перед установкой Intel Quartus FPGA devtool, а Octave уже сжимается следующим образом:

1,55 ГБ Размер данных на диске: 839 ГБ Содержит 34,362 файлов, 1,955 папок

Этот материал пишется один раз и читается миллионы раз во время сборки проекта. Имеет смысл потратить немного ресурсов процессора, чтобы распаковать его и сэкономить, возможно, половину вашего драгоценного места на SSD.

Вам нужно дважды проверить, чтобы знать. Сжатый. Несжатый. Забудьте про износ на SSD. Вам нужен быстрый ssd и процессор, поэтому узких мест не возникает.

В наши дни SSD объемом 512 ГБ стоит 50 долларов. До сих пор для меня самый быстрый доступ к диску - это использование Linux, где это возможно, и механизм очереди дисков LIFO. Скорее, чем CFQ.

Windows 10 создает бесконечную дисковую активность с 12 ГБ оперативной памяти, установленной на моем ноутбуке. Linux mint загружается, и почти нулевой доступ к диску происходит после. Если вы не инициируете это. У Windows просто есть способ занять себя без видимых задач.