Я узнал это:
Причина заключается в том, что gzip
работает (с точки зрения скорости процессора и скорости поиска HD в наши дни) очень низкие размеры буфера .
Он считывает несколько килобайт из входного файла, сжимает его и сбрасывает в выходной файл. Принимая во внимание тот факт, что для этого требуется поиск по жесткому диску, в секунду можно выполнить всего несколько операций.
Причина, по которой мое выступление не масштабировалось, в том, что он уже gzip
искал как сумасшедший.
Я работал с этим с помощью buffer
утилиты Unix :
buffer -s 100000 -m 10000000 -p 100 < file1.json | gzip > file1.json.gz
Буферизуя большую часть ввода перед отправкой в gzip, количество маленьких запросов может быть значительно уменьшено. Варианты:
-s
и -m
должны указать размер буфера (я считаю, что это в КБ, но не уверен)
-p 100
гарантирует, что данные передаются в gzip только после заполнения буфера на 100%
Запустив четыре из них параллельно, я мог получить пропускную способность 4 * 25 МБ / с, как и ожидалось.
Мне все еще интересно, почему gzip не позволяет увеличивать размер буфера - таким образом, это довольно бесполезно, если он запускается на вращающемся диске.
РЕДАКТИРОВАТЬ : я опробовал еще несколько программ сжатия поведения:
bzip2
обрабатывает только 2 МБ / с благодаря более сильному / более интенсивному сжатию ресурсов процессора
lzop
Похоже, что он позволяет увеличивать буферы: 70 МБ / с на ядро, а 2 ядра могут максимально использовать мой HD без чрезмерного поиска
dd
сделать то же самое?