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

Question

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

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

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

Answer 1

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

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

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

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

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

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

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

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

---

Резюме:

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

Answer 2

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

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

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

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

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

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

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

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

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

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

Answer 3

Никто не говорит о проблеме мэра на не 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 не отправляет несжатые данные на диск, кэш записи 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 КБ.

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

Файловые системы на SSD с кластером 4KiB теряют свою скорость, в большинстве случаев теряются более чем на 50% ... посмотрите какие-либо тесты для тестирования с различными размерами блоков, от 512B до 2MB, большая часть 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 отличается от 4 КБ, поскольку сжатие NTFS работает только на разделах NTFS с размером кластера 4 КБ.