Сжатие для повышения производительности записи на жесткий диск

Question

В современной системе можно улучшить скорость записи на локальный жесткий диск путем сжатия выходного потока?

Этот вопрос связан с тем делом, с которым я работаю, когда программа последовательно генерирует и сбрасывает около 1-2 ГБ данных текстового журнала в необработанный текстовый файл на жестком диске, и я думаю, что это связано с IO. Могу ли я ожидать сокращения времени выполнения за счет сжатия данных до того, как они попадут на диск, или затраты на сжатие съедят любую выгоду, которую я смогу получить? Повлияет ли на это наличие второго бездействующего ядра?

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

---

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

Answer 1

Да, да, да, абсолютно.

Посмотрите на это так: определите максимальную скорость записи на непрерывный диск в мегабайтах в секунду. (Идите вперед и измерьте это, время огромного написания или что-то в этом роде.) Скажем, 100 Мбит / с. Теперь возьмите скорость вашего процессора в мегагерцах; скажем, 3Ghz = 3000 МГц. Разделите скорость процессора на скорость записи на диск. Это количество циклов, которые процессор тратит бездействующим, и которые вы можете потратить на байт на сжатие. В этом случае 3000/100 = 30 циклов на байт.

Если бы у вас был алгоритм, который мог бы сжать ваши данные на 25% для эффективной скорости записи 125 Мбит / с, у вас было бы 24 цикла на байт для его запуска, и он был бы свободным , потому что Процессор в любом случае не будет делать что-либо еще в ожидании сбивания диска. 24 цикла на байт = 3072 цикла на 128-байтовую строку кэша, легко достижимо.

Мы делаем это все время при чтении оптических носителей.

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

Answer 2

Да, это было правдой не менее 10 лет. Об этом есть документы по операционным системам. Я думаю, что Крис Смолл, возможно, работал над некоторыми из них.

Для скорости gzip / zlib сжатие на более низких уровнях качества довольно быстрое; если это не достаточно быстро, вы можете попробовать FastLZ . Быстрый способ использовать дополнительное ядро ​​- просто использовать popen(3) для отправки вывода через gzip.

Answer 3

Лаборатория по файловым системам и хранилищу из Stony Brook опубликовала довольно обширную оценку производительности (и энергии) сжатия файловых данных на серверных системах на конференции IBM по исследованию систем SYSTOR в этом году: бумага в цифровой библиотеке ACM , презентация .

Результаты зависят от

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

Например, при измерениях на бумаге использование текстовой рабочей нагрузки и серверной среды с использованием lzop с низким усилием сжатия выполняется быстрее, чем обычная запись, но bzip и gz не .

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

Answer 4

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

Answer 5

Windows уже поддерживает сжатие файлов в NTFS, поэтому все, что вам нужно сделать, это установить флаг «Сжатый» в атрибутах файла. Затем вы можете измерить, стоило ли оно того или нет.

Answer 6

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

Answer 7

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

Как правило, в наши дни сжатие / распаковка обрабатываются на более низком уровне, чем вы пишете, например, на уровне ввода-вывода базы данных.

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

Answer 8

Если эта конкретная машина часто связана с IO, Другой способ ускорить его - установить RAID-массив. Это дало бы ускорение каждой программе и каждому виду данных (даже несжимаемым данным).

Например, популярная конфигурация RAID 1 + 0 с 4 суммарными дисками обеспечивает ускорение почти в 2 раза.

Почти такая же популярная конфигурация RAID 5 с теми же четырьмя дисками дает ускорение почти в 3 раза.

Относительно просто настроить массив RAID со скоростью, в 8 раз превышающей скорость одного диска.

С другой стороны, высокие коэффициенты сжатия не так просты. Сжатие «просто» 6,30 до одного даст вам денежный приз за то, что вы побили текущий мировой рекорд по сжатию (приз Хаттера).

Answer 9

Если вы ограничены вводом / выводом, сохраняя читаемый человеком текст на жестком диске, я ожидаю, что сжатие сократит общее время выполнения.

Если у вас свободное 2 ГГц ядро ​​и относительно быстрый 100 МБ / с потоковый жесткий диск, Для того чтобы вдвое сократить время регистрации, требуется сжатие не менее 2: 1 и не более примерно 10 циклов ЦП на несжатый байт, чтобы компрессор обдумывал данные. При использовании двухтрубного процессора это (очень приблизительно) 20 инструкций на байт.

Я вижу, что LZRW1-A (один из самых быстрых алгоритмов сжатия) использует от 10 до 20 инструкций на байт и сжимает типичный текст на английском языке примерно в 2: 1. В верхнем конце (20 инструкций на байт) вы находитесь на грани между ограничением ввода-вывода и ограничением процессора. В среднем и нижнем конце вы все еще ограничены вводом-выводом, так что есть несколько доступных циклов (немного) для немного более сложного компрессора, чтобы обдумывать данные немного дольше.

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

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

Я вижу список сжатых файловых систем на основе FUSE и слышу, что NTFS также поддерживает сжатые разделы.

Answer 10

Это зависит от множества факторов, и я не думаю, что есть один правильный ответ. Это сводится к этому:

Можете ли вы сжать необработанные данные быстрее, чем производительность записи на вашем диске, умноженная на степень сжатия, которую вы достигаете (или кратную скорость, которую вы пытаетесь получить), учитывая пропускную способность ЦП, которую вы можете выделить для этой цели?

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

Относительно конкретного мнения (угадайте !?) к вопросу о дополнительных ядрах. Если вы сожмете сжатие данных и будете поддерживать ядро ​​(я) с высокой степенью сжатия текста, вероятно, такой метод принесет свои плоды. Но это всего лишь предположение. В однопоточном приложении, чередующемся между записью на диск и операциями сжатия, это кажется мне гораздо менее вероятным.