Использование хорошего приоритета планирования с помощью сценария tar / gzip cron

Есть предостережения, на которые следует обратить внимание. Поскольку в вопросе не указывается точная ОС (но подразумевается, что это некоторая Unix-подобная ОС), список предостережений будет зависеть от конкретной ОС и версии. Наиболее важные из них:

nice предназначен для того, чтобы влиять на количество процессорного времени, отведенного процессу, но не на объем оперативной памяти или емкости ввода-вывода. Таким образом, вместо ожидаемого эффекта другие возможные результаты включают:

• Резервное копирование занимает больше времени из-за меньшего количества процессорного времени. Но он будет использовать столько же ОЗУ, сколько раньше, и теперь он будет использовать эту ОЗУ дольше. Система замедляется из-за того, что у нее меньше ОЗУ для других целей, и эта медлительность будет длиться дольше, чем раньше.
• Использование nice не имеет никакого эффекта, потому что процесс резервного копирования был связан с вводом-выводом с самого начала, а планирование ввода-вывода не зависит от nice. Если ОС является последней версией Linux, на планирование ввода-вывода могут или не могут влиять nice в зависимости от того, что ionice настройка уже используется.

Более того, даже точное влияние на планирование ЦП во многом зависит от конкретной операционной системы и настроек. Некоторые ядра имеют настройки, которые позволяют процессу работать с более высоким или более низким приоритетом, чем те, которые доступны с помощью nice команда.

Одно предостережение, с которым я столкнулся сам, похоже, относится к Ubuntu 14.04. В конфигурации по умолчанию он группирует процессы для целей планирования. Затем каждая группа получает изрядную долю процессорного времени. nice влияет только на то, как процессорное время распределяется между процессами внутри такой группы, но не на то, сколько времени выделяется каждой группе. Для меня это полностью подорвало использование nice, потому что процесс с низким приоритетом может отнимать время ЦП у процессов в разных группах.

Я бы выбрал другой подход ...

Нет, я бы не стал возиться с nice для этого. И gzip не так уж и здорово. Кроме того, вы используете gzip -9 что дает максимальную степень сжатия за счет процессора. Вам действительно нужен такой уровень сжатия по сравнению с уровнем по умолчанию (уровень 6)?

Ваша система так сильно нагружается, если вы не использовать gzip уровня 9?

Каковы характеристики вашего сервера? Сколько у вас ЦП и какого типа? cat /proc/cpuinfo

Если у вас несколько процессоров, не могли бы вы использовать pigz вместо? Он многопоточный, немного более эффективен и может намного лучше использовать ресурсы вашей системы.

Некоторые тесты с файлом 1,8 ГБ:

Стандарт gzip (-6 уровень сжатия)

Original file size: 1.8G    CHL0001.TXT 
Compression time: 0m18.335s
Compressed file size: 85M   CHL0001.TXT.gz
Decompression time: 0m6.300s

gzip -9 (максимальное сжатие)

Original file size: 1.8G    CHL0001.TXT
Compression time: 1m29.432s
Compressed file size: 75M   CHL0001.TXT.gz
Decompression time: 0m6.325s

pigz (-6 уровень сжатия)

Original file size: 1.8G    CHL0001.TXT
Compression time: 0m1.878s
Compressed file size: 85M   CHL0001.TXT.gz
Decompression time: 0m2.506s

pigz -9 (максимальное сжатие, многопоточный)

Original file size: 1.8G    CHL0001.TXT
Compression time: 0m5.611s
Compressed file size: 76M   CHL0001.TXT.gz
Decompression time: 0m2.489s

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

Я понимаю, что это отклоняется от исходного вопроса, но он остается в теме эффективности (вы упоминаете «огромные нагрузки на мой сервер») ...

Я делаю вывод (или предполагаю!) Из того, что вы опубликовали, что вы создаете tar содержащий набор файлов, а затем gzip- результат. Вы можете сэкономить много дискового ввода-вывода (и временного требования к пространству), подключив один напрямую к другому:

tar cf - /path/to/stuff | gzip > archive.tar.gz

Вы можете обнаружить, что это существенно влияет на общее затраченное время.