Будет ли использование современной компрессии в современной системе улучшать общую производительность?

Кажется, что увеличение процессора на некоторое время опередило скорость диска. Принимая во внимание настольный компьютер или ноутбук с современным двухъядерным процессором Intel / AMD и одним средним SATA-диском, даст ли компрессия на большинстве всех дисков более высокую общую производительность? В принципе, уменьшенная пропускная способность диска более чем компенсирует повышенную нагрузку на процессор? Я уверен, что реальный ответ «это зависит от того, что вы делаете». Задавая этот вопрос, я надеюсь найти кого-то, кто выполнил эту задачу и привел несколько примеров или подводных камней.

Да, сжатие диска может обеспечить лучшую производительность при определенных обстоятельствах:

• Ваше приложение ограничено пропускной способностью диска: современные процессоры и (де) алгоритмы сжатия могут работать с гораздо большей пропускной способностью, чем современные диски при длительной передаче. Любое сокращение количества данных, перемещаемых на дисковые диски или с них, является выигрышем в этих обстоятельствах.
• Сжатие данных, поступающих на жесткие диски, занимает меньше времени, чем разница во времени передачи, и у вас есть запасные циклы ЦП

Есть причина, по которой как в ZFS, так и в Btrfs, оба последних проекта с «зелеными полями», предусмотрены условия сжатия.

В пространстве HPC, когда приложение выполняет контрольные точки из памяти на диск, процессоры часто вообще не делают ничего полезного. Это время по сути чисто накладные расходы. Любое использование процессоров для сокращения этого времени является победой.

Сжатие диска никогда не даст вам лучшей производительности.

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

Вы предполагаете, что необходимость переносить меньше данных с / на диск может повысить производительность; но передача больших данных почти никогда не является узким местом ввода / вывода: настоящие узкие места - это время поиска и задержка. Современные жесткие диски очень быстро справляются с устойчивой передачей данных с большими файлами, что замедляет их - небольшие передачи со всего диска.

Некоторые сценарии:

• Медиа файлы. Они обычно уже сжимаются сами по себе (JPEG, MPEG, MP3), поэтому сжатие их на уровне файловой системы совсем не поможет; это вместо этого ухудшит вещи, потому что ресурсы CPU уже необходимы, чтобы закодировать / декодировать их.
• Базы данных. Они обычно считываются / записываются в виде небольших случайных пакетов, поэтому их сжатие не только не принесет никакой пользы, но и ухудшит производительность, поскольку СУБД не может правильно определить, где на диске находятся физические данные, к которым она должна получить доступ. сохраняются.
• Файл подкачки. Обычно это довольно большой размер, но ОС должна обрабатывать очень маленькие порции данных и делать это очень точно («Чтение 4K по физическому адресу X»); Сжатие обычно невозможно, но даже если бы это было так, это было бы полной тратой времени и ресурсов: это обеспечивало бы практически нулевое сжатие из-за природы «полного случайного набора данных» этого файла.

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

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

Вы ответили на свой вопрос! это зависит, действительно, ответ.

Лучшее обобщение, которое я могу сделать:

Если у вас есть приложение базы данных с ограничением чтения с диска , то да! производительность лучше.

Я не думаю, что это относится к большинству действий, которые вы будете выполнять на настольном компьютере / ноутбуке.

В моем домене (SQL Server) я знаю, что создание отчетов для баз данных при больших нагрузках чтения может повысить производительность при использовании сжатия. Я знаю, что то же самое верно для MySQL.

У Microsoft есть официальный документ об их функциях сжатия в SQL Server 2008. Не совсем легкое чтение, если вы не администратор базы данных, но вот одна диаграмма, которая поддерживает мое обобщение:

Скорость процессора всегда была выше скорости диска. ИМХО, сжатие увеличит накладные расходы и тем самым снизит производительность.

Я читал нечто похожее на это вчера относительно OSX и его сжатия файловой системы - в основном ответ вращается вокруг того, что вы хотите сжать - в этом примере он говорит о данных «FAT»; файловые структуры, свойства, метаданные и т. д., которые при совместном хранении могут быть сжаты для экономии места и считывания в процессор быстрее, чем поиск головы в любом месте, чтобы найти данные для каждого файла ...

Во всяком случае, стоит прочитать, если вы думаете о таких вещах :-p

Но сжатие - это не просто сохранение дискового пространства. Это также классический пример торговли циклами ЦП для снижения задержки ввода-вывода и пропускной способности. За последние несколько десятилетий производительность процессора возросла (а вычислительные ресурсы стали более многочисленными, подробнее об этом позже) с гораздо большей скоростью, чем производительность диска. Современное время поиска жесткого диска и задержки вращения все еще измеряются в миллисекундах. За одну миллисекунду процессор с частотой 2 ГГц проходит два миллиона циклов. И затем, конечно, еще есть фактическое время передачи данных для рассмотрения.

Конечно, несколько уровней кэширования во всей ОС и аппаратном обеспечении работают мощно, чтобы скрыть эти задержки. Но эти биты должны сойти с диска в какой-то момент, чтобы заполнить эти кэши. Сжатие означает, что нужно передавать меньше битов. Учитывая почти комическое изобилие ресурсов ЦП на современном многоядерном Mac при нормальном использовании, общее время, необходимое для передачи сжатой полезной нагрузки с диска и использования ЦП для распаковки его содержимого в память, обычно будет намного меньше, чем время потребуется перенести данные в несжатом виде.

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

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

Формат тома HFS + хранит всю свою информацию о файлах - метаданные - в двух основных местах на диске: файл каталога, в котором хранятся даты файлов, разрешения, владелец и множество других вещей, и файл атрибутов, в котором хранятся «именованные вилки». «.

Расширенные атрибуты в HFS + реализованы в виде именованных вилок в файле атрибутов. Но в отличие от разветвлений ресурсов, которые могут быть очень большими (вплоть до максимального размера файла, поддерживаемого файловой системой), расширенные атрибуты в HFS + хранятся «встроенными» в файле атрибутов. На практике это означает ограничение около 128 байт на атрибут. Но это также означает, что головке диска не нужно отправляться в другую часть диска, чтобы получить реальные данные.

Как вы можете себе представить, к дисковым блокам, которые составляют файлы Каталога и Атрибутов, часто обращаются, и, следовательно, с большей вероятностью, чем большинство, находится где-то в кеше. Все это позволяет сделать полное хранение файла, включая как его метаданные в данных, в файлах каталога и атрибутов с B-древовидной структурой, как выигрыш в общей производительности. Даже восьмибайтовая полезная нагрузка, которая расширяется до 25 байтов, не является проблемой, если она все еще меньше, чем размер блока выделения для обычного хранения данных, и до тех пор, пока все это вписывается в узел B-дерева в файле атрибутов, который в любом случае ОС должна читать целиком.

Есть и другие существенные вклады в уменьшение занимаемой диском памяти Snow Leopard (например, удаление ненужных локализаций и файлов «designable.nib»), но сжатие HFS + является наиболее технически интересным.

От: http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/3

Сжатие диска Microsoft ужасно СТАРОЕ. Это вряд ли сравнимо по соотношению с методом ARJ 80-х годов. Но даже сжатие Microsoft МОЖЕТ обеспечить лучшую производительность на очень медленных (портативных) жестких дисках. Особенно, если достаточно оперативной памяти для кэширования записи и предотвращения чрезмерной записи.

Процесс записи является слабым местом любого метода сжатия с произвольным доступом.

Итак, если вам нужен сжатый диск, вам лучше перейти на какой-нибудь Linux.

Сжатие дисков также очень подходит для RAM-накопителей, не нужно объяснять почему.

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

Короче говоря, нет, вы, вероятно, не выиграете.

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