Эта темаобсуждает сжатие NTFS на HDD как метод повышения производительности доступа к диску и приходит к выводу, что оно в этом плане чаще всего неэффективно. Но я всегда рассматривал сжатие как способ экономии места и понял его эффективность в этом. А теперь у меня SSD, где место стоит дорого, а потери производительности, например, при чтении/записи 2 кластеров вместо 1, намного ниже.
С другой стороны, поскольку SSD намного быстрее HDD, я бы ожидал, что более высокая пропускная способность приведет к более высокой загрузке ЦП. Может ли это стать проблемой? Есть еще мысли по этому поводу?
Мне нравится эффект экономии места, он не очень большой, но он есть. Но если производительность имеет значение, я бы лучше отключил его:
решение1
Майкрософтнаписал это некоторое время назад в блоге:
NTFS сжимает файлы, разделяя поток данных на CU (это похоже на то, как работают разреженные файлы). Когда содержимое потока создается или изменяется, каждый CU в потоке данных сжимается индивидуально. Если сжатие приводит к уменьшению на один или несколько кластеров, сжатый блок будет записан на диск в сжатом формате. Затем разреженный диапазон VCN добавляется к концу сжатого диапазона VCN для выравнивания (как показано в примере ниже). Если данные не сжимаются достаточно, чтобы уменьшить размер на один кластер, то весь CU записывается на диск в несжатом виде.
Такая конструкция делает случайный доступ очень быстрым, поскольку для доступа к любому отдельному VCN в файле требуется распаковать только один CU. К сожалению, большой последовательный доступ будет относительно медленнее, поскольку для выполнения последовательных операций (например, резервного копирования) требуется распаковка многих CU.
Хотя сжатие файловой системы NTFS может сэкономить место на диске, сжатие данных может отрицательно сказаться на производительности.Сжатие NTFS имеет следующие характеристики производительности. Когда вы копируете или перемещаете сжатый файл NTFS в другую папку, NTFS распаковывает файл, копирует или перемещает файл в новое место, а затем повторно сжимает файл. Такое поведение происходит даже тогда, когда файл копируется или перемещается между папками на одном компьютере. Сжатые файлы также расширяются перед копированием по сети, поэтому сжатие NTFS не экономит пропускную способность сети.
Поскольку сжатие NTFSпроцессоро-интенсивный, стоимость производительности более заметна на серверах, которые часто ограничены процессором. Серверы с большой нагрузкой и большим объемом трафика записи являются плохими кандидатами для сжатия данных.Однако вы можете не заметить существенного снижения производительности на серверах, предназначенных только для чтения, в основном для чтения или слабо загруженных серверах.
Если вы запускаете программу, которая использует журнал транзакций и постоянно пишет в базу данных или журнал, настройте программу для хранения ее файлов на томе, который не сжат. Если программа изменяет данные через сопоставленные разделы в сжатом файле, программа может создавать «грязные» страницы быстрее, чем сопоставленный писатель может их записать. Такие программы, как Microsoft Message Queuing (также известный как MSMQ), не работают со сжатием NTFS из-за этой проблемы.
Поскольку домашние папки пользователей и перемещаемые профили используют много операций чтения и записи, Microsoft рекомендует размещать домашние папки пользователей и перемещаемые профили на томе, который не имеет сжатия NTFS в родительской папке или в корне тома.
Краткое содержание:
сжимать только небольшие файлы, которые никогда не изменяются (только чтение, но не запись), поскольку чтение выполняется быстро, а запись требует распаковки и нового сжатия, что потребляет ресурсы ЦП, а тип хранилища не так важен.
решение2
Поскольку Клаудио говорит много подробностей, я собираюсь повторить его мнение, которое совпадает и с моим: я видел те же эффекты, попробовав то, что он говорит.
Для SSD нельзя использовать сжатие NTFS.
Теперь перечислю некоторые мотивы такого утверждения:
Мотив №1: Это убьет SSD гораздо быстрее, поскольку он выполняет две записи; сжатие NTFS всегда записывает несжатые данные перед началом сжатия в ОЗУ, а затем перезаписывает сжатые данные, только если выигрыш составляет не менее 4 КБ.
Мотив №2: Использование кластера NTFS размером 4 КБ на SSD приводит к потере 50% скорости SSD. Проверьте любой тест и увидите, что блоки размером 128 КБ делают SSD в два раза быстрее, чем при использовании блоков размером 4 КБ. Сжатие NTFS можно использовать только на разделах NTFS размером 4 КБ.
Мотив №3: Существуют контейнеры (например, PISMO File Mount), которые могут создавать контейнеры, которые рассматриваются как сжатие и/или шифрование «на лету». Такие контейнеры выполняют сжатие в оперативной памяти и не отправляют несжатые данные на диск перед перезаписью в сжатом виде. Более того, PISMO обеспечивает лучшую степень сжатия, чем NTFS.
Мотивов гораздо больше, но это самые важные.
Другой момент — СКОРОСТЬ. Любое сжатие выполняется на ЦП, поэтому, если у вас не очень быстрый ЦП (в NTFS для этого используется однопоточный режим, а в некоторых контейнерах — многопоточный), то чтение/запись при сжатии будут происходить очень медленно. В худшем случае, у вас может быть очень быстрый ЦП, но если он используется для других задач (например, рендеринга, транскодирования и т. д.), то ресурсов ЦП для сжатия не останется, поэтому производительность снова будет низкой.
Сжатие NTFS хорошо подходит только для традиционных медленных дисков, когда процессор не используется в полной мере, но оно требует хорошей дефрагментации после каждой записи (на уровне файлов), поскольку каждый блок размером 64 КБ (сжатый или нет) записывается в позицию, кратную 64 КБ; единственный способ упаковать такие фрагменты — выполнить дефрагментацию такого файла после сжатия (или записи в сжатую папку).
ПД: Будьте осторожны, мы говорим о Windows на реальном оборудовании, а не внутри виртуальных машин. Важно то, кто пишет на физический носитель. У других могут быть слои кэша, которые могут смягчить последствия и также значительно улучшить ситуацию.
решение3
Я вижу комментарии других, и мне кажется, что люди часто забывают о самом полезном сценарии, где сжатие файлов/папок NTFS имеет большое преимущество на SSD: современные инструменты разработки. МойMatlab с университетской лицензиейимеет в своей (доступной только для чтения для обычного пользователя) папке установки следующие объемы данных:
28,5 ГБ Данные 30,6 ГБ Размер на диске Содержит 729.246 файлов и 15.000 папок (!!!)
Это на моем ноутбуке с SSD на 500 ГБ, где раздел Windows занимает 200 ГБ.
Я знаю, что Matlab немного экстремальный в этом отношении, но многие devtools имеют схожие свойства: тонна небольших, сильно сжимаемых текстовых файлов (заголовки, код, XML-файлы). Я сжимаю Matlab прямо сейчас, перед установкойIntel Quartus ПЛИСdevtool иОктавауже сжат следующим образом:
1,55 ГБ Размер данных на диске: 839 ГБ Содержит 34,362 файлов 1,955 папок
Этот материал пишется один раз и читается миллионы раз во время сборки проекта. Имеет смысл тратитьнекоторыймощности процессора, чтобы распаковать его и сэкономить, возможно, половину драгоценного места на вашем SSD-накопителе.
решение4
Вам нужно провести бенчмарк дважды, чтобы узнать. Сжатый. Несжатый. Забудьте об износе SSD. Вам нужен быстрый SSD и CPU, чтобы не возникло узкое место.
SSD на 512 ГБ стоит 50 баксов в наши дни. Самый быстрый доступ к диску для меня на данный момент — это использование Linux, где это возможно, и механизма очереди диска LIFO. Вместо CFQ.
Windows 10 создает бесконечную дисковую активность с 12 ГБ оперативной памяти, установленной на моем ноутбуке. Linux mint загружается и после этого происходит почти нулевой доступ к диску. Если только вы не инициируете это. Windows просто имеет способ занять себя без видимых задач.