Швидко стискайте велику кількість великих файлів

У мене щоденно генерується близько 200 ГБ даних журналів, які розподіляються між приблизно 150 різними файлами журналів.

У мене є сценарій, який переміщує файли у тимчасове місце і робить tar-bz2 у тимчасовому каталозі.

Я отримую хороші результати, оскільки журнали в 200 ГБ стискаються приблизно до 12-15 ГБ.

Проблема полягає в тому, що стискати файли потрібно назавжди. Робота з крон працює щодня о 2:30 та продовжує виконуватись до 5:00 - 6:00.

Чи є спосіб покращити швидкість стиснення і швидше виконати завдання? Будь-які ідеї?

Не турбуйтеся про інші процеси та все, що місце стиснення знаходиться в NAS , і я можу запустити монтування NAS на спеціальному VM та запустити сценарій стиснення звідти.

Ось результат зверху для довідки:

top - 15:53:50 up 1093 days,  6:36,  1 user,  load average: 1.00, 1.05, 1.07
Tasks: 101 total,   3 running,  98 sleeping,   0 stopped,   0 zombie
Cpu(s): 25.1%us,  0.7%sy,  0.0%ni, 74.1%id,  0.0%wa,  0.0%hi,  0.1%si,  0.1%st
Mem:   8388608k total,  8334844k used,    53764k free,     9800k buffers
Swap: 12550136k total,      488k used, 12549648k free,  4936168k cached
 PID  USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 7086 appmon    18   0 13256 7880  440 R 96.7  0.1 791:16.83 bzip2
7085  appmon    18   0 19452 1148  856 S  0.0  0.0   1:45.41 tar cjvf /nwk_storelogs/compressed_logs/compressed_logs_2016_30_04.tar.bz2 /nwk_storelogs/temp/ASPEN-GC-32459:nkp-aspn-1014.log /nwk_stor
30756 appmon    15   0 85952 1944 1000 S  0.0  0.0   0:00.00 sshd: appmon@pts/0
30757 appmon    15   0 64884 1816 1032 S  0.0  0.0   0:00.01 -tcsh

Перший крок - розібратися, що таке вузьке місце: це дисковий введення / вивід, мережевий ввод / вивід чи процесор?

Якщо вузьким місцем є введення / виведення диска, ви не можете багато чого зробити. Переконайтесь, що диски не обслуговують багато паралельних запитів, оскільки це може лише знизити продуктивність.

Якщо вузьким місцем є мережевий ввод-вивід, запустіть процес стиснення на машині, де зберігаються файли: запуск його на машині з процесором-програвачем, що допомагає, лише якщо ЦП є вузьким місцем.

Якщо вузьким місцем є процесор, то перше, що слід врахувати, - це використання алгоритму швидшого стиснення. Bzip2 не обов'язково є поганим вибором - головна його слабкість - швидкість декомпресії - але ви можете використовувати gzip і пожертвувати деяким розміром для швидкості стиснення, або спробувати інші формати, такі як lzop або lzma. Ви також можете налаштувати рівень стиснення: bzip2 за замовчуванням -9(максимальний розмір блоку, таким чином максимальне стиснення, але також найдовший час стиснення); встановити змінну середовища BZIP2на таке значення, як -3спробувати рівень стиснення 3. Цей потік і цей потік обговорюють загальні алгоритми стиснення; зокрема ця публікація в блозі, на яку посилається derobert, дає деякі орієнтири, які дозволяють припустити, що gzip -9абоbzip2з низьким рівнем може бути хорошим компромісом порівняно з bzip2 -9. Цей інший орієнтир, який також включає lzma (алгоритм 7zip, тому ви можете використовувати 7zзамість цього tar --lzma), дозволяє припустити, що lzmaна низькому рівні швидше досягти коефіцієнта стиснення bzip2. Практично будь-який вибір, крім bzip2, покращить час декомпресії. Майте на увазі, що коефіцієнт стиснення залежить від даних, а швидкість стиснення залежить від версії програми стиснення, від того, як вона була складена та від процесора, на якому вона виконується.

Інший варіант, якщо вузьким місцем є процесор, і у вас є кілька ядер, - це паралелізація стиснення. Є два способи зробити це. Одна з функцій алгоритму стиснення - стиснути файли окремо (окремо або в декількох групах) і parallelпаралельно виконувати команди архівування / стиснення. Це може зменшити коефіцієнт стиснення, але збільшує швидкість пошуку окремого файлу та працює з будь-яким інструментом. Інший підхід полягає у використанні паралельної реалізації інструменту стиснення; ця нитка перелічує кілька.

Ви можете встановити pigz, паралельно gzip та використовувати tar при багатопотоковому стисненні. Подобається:

tar -I pigz -cf file.tar.gz *

Де -Iваріант:

-I, --use-compress-program PROG
  filter through PROG

Звичайно, якщо ваш NAS не має декількох ядер / потужний процесор, ви все одно обмежені потужністю процесора.

Швидкість жорсткого диска / масиву, на якій працює VM та стискання, також може бути вузьким місцем.

На сьогодні найшвидший і найефективніший спосіб стиснення даних - це генерувати менше їх.

Які типи колод ти генеруєш? 200 Гб щодня звучить як дуже багато (якщо ви не Google або інший провайдер ...), врахуйте, що 1 Мб тексту становить близько 500 сторінок, тож ви генеруєте еквівалент 100 мільйонам сторінок тексту в день, заповнити бібліотеку конгресу за тиждень.

Подивіться на дані своїх журналів, чи зможете ви якимось чином їх зменшити і все-таки отримати те, що вам потрібно з журналів. Наприклад, зменшивши рівень журналу або використовуючи термінальний формат журналу. Або якщо ви використовуєте журнали для статистики, обробляйте статистику на ходу та скидайте файл із підсумком, а потім фільтруйте журнали перед стисненням для зберігання.

Ви можете зменшити кількість стиснення (з точки зору заощадженого місця), щоб зробити його швидшим. Для початку bzip2 набагато повільніше, ніж gzip, хоча він стискає менше. Ви також можете змінити рівень стиснення bzip2, gzip або більшості програм стиснення на розмір торгівлі для швидкості.

Якщо ви не бажаєте торгувати розміром швидкості, ви, ймовірно, можете отримати однаковий розмір або менший розмір, все одно отримуючи підвищення швидкості за допомогою компресора, який використовує LZMA (наприклад, xz).

Якщо ви шукаєте, ви знайдете орієнтири, але найкраще робити кілька тестів із власним файлом на вашому цільовому обладнання.

Якщо єдиною вимогою є стиснення швидко , я рекомендую lz4 дуже високо.

Він використовується в багатьох місцях, де швидкість стиснення важливіша, ніж коефіцієнт стиснення (наприклад, файлові системи з прозорим стисненням, як ZFS)