Более быстрый (несжатый) инструмент архивации, чем tar?

Прежде всего убедитесь, что у вас есть права на исполнение для вашего скрипта.

И затем

Запустите ваш сценарий, используя ./ portblock.sh или используя sh portblock.sh .

Если вам не нравится запускать сценарий вышеупомянутым способом, обновите переменную PATH в каталоге сценария.

2
01.09.2016, 22:16
1 ответ

Пропускная способность процессора x86-64 составляет порядка 64 ГБ / с, поэтому я не думаю, что это ваша проблема. Это вообще линукс x86-64 или еще что? Скорее всего, проблема в том, что некоторая работа процессора выполняется за транзакцию, и он использует слишком маленькие блоки. Попробуйте:

strace -fo /tmp/tar.rw.txt -eread, напишите tar -cvf / dev / nst0 --totals --warning = no-file-changed $ OLDEST_DIR

Чтобы узнать, что tar хочет сделать с блокировкой ввода-вывода в итоговом файле /tmp/tar.rw.txt. Скорее всего, вы обнаружите, что он читает и записывает блоки по 10 КБ. Вы можете исправить это с помощью флага -b , который якобы по умолчанию равен 20. Готов поспорить, ваше оборудование может обрабатывать ввод-вывод в мегабайтах, и ваша ОС разделит его обратно, если не сможет, поэтому попробуйте -b $ [1024 * 2 * 32] для транзакций 32 МБ.

Затем вы должны проверить, что ОС хочет делать с транзакциями. Попробуйте tar с новым значением -b , убедитесь, что у вас установлен sysstat , и пока он работает, проверяйте iostat -xm 4 и следите за счетчиками.Главное, на что следует обратить внимание, - это столбец avgrq-sz. Если разбиения не происходит, это должно быть около 64000. Если оно разбивается, ваша ОС считает, что не может прочитать или записать такое количество байтов за одну транзакцию. Это тема сама по себе, но вы можете быстро увеличить пределы, отметив диск (я думаю, что там должен быть nst0) и

cd /sys/block/nst0/queue
cat max_hw_sectors_kb > max_sectors_kb`

, и то же самое с каждым слоем диска, с которого вы читаете (включая слои lvm и dm). Это критично , что вы увеличиваете max_sectors_kb с самого низкого (sda) уровня вначале и с самого высокого (например, dm23) уровня в конце. Рекурсивно проверьте наличие / sys / block / / holders / * / holders / * / .... .

Теперь с этими новыми настройками вы должны быть осторожны с двумя вещами. Один из них - это md5sum исходных файлов, tar и untar с ленты и проверка md5sums, чтобы убедиться, что файлы все еще записываются правильно. -b не должно вызывать подобных проблем, но я не тестировал ваше ленточное оборудование и т. Д. Во-вторых, чтобы убедиться, что у вас не заканчивается ОЗУ из-за больших размеров транзакций. Возможно, вам потребуется убедиться, что sysctl vm.min_free_kbytes достаточно большой, потому что, если он заканчивается во время дисковой транзакции, происходят действительно плохие вещи.

2
27.01.2020, 22:11

Теги

Похожие вопросы