Решено: архивирование большого кол-ва файлов

[azsx]

У меня дебиан. На компе (2,7гц, 2 ядра, Е8400, загрузка цп и без архивирования 100%) надо каждые несколько дней архивировать большое количество файлов (сейчас 900 тысяч). Файлы от 7 кб до 90 кб, в основном 50 кб. Место на винте много, винт сата загружен не сильно. Проводится архивирование, затем файлы копируются на виндос машину и распаковываются (по идее). Улучшить тех характеристики машины-сервера я сейчас не могу. Могу выделить из 8 гб оперативки 2 гб, не больше. Меня не устраивает скорость архивирования команды tar czvf
Вопрос, 1. есть ли какие либо другие решения? Скорость работы главное.
2. Не может быть такое, что я путаюсь, и скорость архивирования нормальная и лучше ничо не придумаешь, а вопрос именно в открывании большого кол-ва файлов?

[DaemonTux]

Ну если у вас 100% загрузка CPU То конечно вас скорость сжатия не устроит. Так как сжатие требует много вычислений.

Ну во первых может вы таки поделитесь что делает ваш комп. Может для начала его стоит понастроить. Чтобы меньше процессор кушался.

По сабжу. Ну есть несколько вариантов копирования. Можно и без сжатия архивировать. В чистый тар. Должно получиться быстрее так как проц будет задействован по минимому.
Можно заюзать rsync.
Если эти 900 тыс файлов не все изменяются Может сделать инкрементальный бекап.
Если эти файлы не все изменяются. еще и текстовые может имеет смысл попробовать git

В общем больше подробностей

[azsx]

Ну во первых может вы таки поделитесь что делает ваш комп. Может для начала его стоит понастроить. Чтобы меньше процессор кушался.

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

Если эти 900 тыс файлов не все изменяются Может сделать инкрементальный бекап.
Если эти файлы не все изменяются. еще и текстовые может имеет смысл попробовать git

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

Можно и без сжатия архивировать. В чистый тар. Должно получиться быстрее так как проц будет задействован по минимому.

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

[drBatty]

Ну если у вас 100% загрузка CPU То конечно вас скорость сжатия не устроит. Так как сжатие требует много вычислений.

не много. Я очень сомневаюсь, что сжатие как-то замедляет (может даже немного ускоряет, ибо меньше писать). Это конечно я про gzip

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

на 99% будет только хуже. Ибо tar -cz делает то-же, что и tar -c | gzip, т.е. пакует, и сразу сживает. Если вы запишете и прочитаете промежуточный файл - будет ещё хуже.

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

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

Код: Выделить всё

find /dir1/ /dir2/ /dir3/ -type f -newer последний_бекап.tgz

Прямо этой-же командой вы можете создать новый архив с посл. файлами, а потом его отправить по назначению, и распаковать в те-же папки.

[azsx]

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

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

[neol]

Если файлы создаются на протяжении достаточно большого отрезка времени, то можно попробовать с помощью inotify отслеживать закрытие файлов и добавлять их в списочек, по которому раз в энное количество минут добавлять эти файлы в архив. Мне кажется для этого лучше подойдет zip, хотя есть вероятность, что вообще ничего хорошего из этого не выйдет. В общем суть в том, чтобы архивировать файлы в процессе их создания, а не после завершения задачи.

inotify, а не find потому что:
- файл будет уже точно полностью записан
- не будет необходимости пробегать все 900к файлов, чтобы найти нужные.

Хотя как вариант можно формировать списочек find'ом, загонять в архив и тут же удалять.

[MrClon]

Что это за файлы, хорошо-ли сжимаются. Жирный-ли у сервера канал в интернет? Может быстрее передавать файлы в не сжатом виде (tar cf если мне не изменяет память).
Что за обработке, значительно уменьшающей их объём, подвергаются файлы? Почему её нельзя делать непосредственно на сервере.
Те приложения в виртуалках действительно активно используют CPU? Аппаратная виртуализация включена? О другой системе виртуализации не задумывался? VB всё-же в основном под десктопы заточен.

P.S. кстати да, стоит задуматься а не вытягивать-ли файлы с сервера чаще.

[azsx]

наверное беда в том, что я не правильно задал вопрос. Надо было спросить, есть ли архивация быстрее gzip в линуксе. drBatty сказал, проц нагружается мало, при расчете производительности архивирования (в моем случае) тормозит систему винт, а не проц.

Что это за файлы, хорошо-ли сжимаются. Жирный-ли у сервера канал в интернет? Может быстрее передавать файлы в не сжатом виде (tar cf если мне не изменяет память).
Что за обработке, значительно уменьшающей их объём, подвергаются файлы? Почему её нельзя делать непосредственно на сервере.
Те приложения в виртуалках действительно активно используют CPU? Аппаратная виртуализация включена? О другой системе виртуализации не задумывался? VB всё-же в основном под десктопы заточен.
P.S. кстати да, стоит задуматься а не вытягивать-ли файлы с сервера чаще.

файлы текстовые, сжатие в 5,5 раз (щас посчитал на одном из архивов в 80 тыщ файлов). Не хочу делать обработку на сервере, так как сперва желательно все подготовить, а потом уже всё обработать., обработка - удаление мусора и грамотная разбивка текстового файла для разных полей в бд (муть короче). Да приложения вбокс активно используют цпу и винт, даже не знаю на е8400 включать виртуализацию? не охота мне тот комп настраивать мне только бы мою задачу решить. Другую систему поставить не могу, программы не пойдут, они привязаны к системе в общем (опять же, мне это не надо). Вытягивать файлы чаще с этого сервера я смысла не вижу, фйлы собираются по миллиону (приблизительно) потом скрипт завершается (надо с другими параметрами запускать). Мне кажется правильнее сперва обрабатывать всеь скрипт, а потом ставить архивацию, это будет в разы быстрее, чем что то там настраивать. На другом впс я такое настрою, когда доберусь, пока я там мучаюсь. Вот на впс винт 5 гб, там очень разумно сделать архивацию по крону, но мне уже предложили способ с файнд.

[MrClon]

наверное беда в том, что я не правильно задал вопрос. Надо было спросить, есть ли архивация быстрее gzip в линуксе. drBatty сказал, проц нагружается мало, при расчете производительности архивирования (в моем случае) тормозит систему винт, а не проц.

Да, но нужно учитывать что у тебя проц уже не слабо нагружен. В общем ещё не известно где узкое место.
Что-бы разгрузить хард можно избавиться от записи сжатого файла на диск. Например сразу писать его на удалённый хост.

даже не знаю на е8400 включать виртуализацию?

Почему нет? Это сильно снизит нагрузку на CPU/производительность виртуальных машин. К тому-же для систем в виртуалках это, кажется, совершенно прозрачно.

[drBatty]

то есть ничего быстрее gzip придумать под линукс нельзя правильно?

под венду - тоже. Вообще, LZ77/LZ78 это насколько я знаю самый быстрый алгоритм (реализация в ZIP & gzip).
Быстрее него только совсем уж тупое сжатие RLE, и ещё немного быстрее сжатие по повторам нулевого байта. Второе реализовано в команде cp (man cp и далее по ссылкам). Вот только вам, с вашими текстами, это НЕ подходит. Просто сжатия никакого не будет.

Надо было спросить, есть ли архивация быстрее gzip в линуксе.

для вашего случая - нет. Мало того, часто сжатие БЫСТРЕЕ, чем простое архивирование (и уж тем более чем копирование).
но конечно нужно проверять в конкретном случае...

[watashiwa_daredeska]

Мало того, часто сжатие БЫСТРЕЕ, чем простое архивирование

Как обычно, надо искать узкое место. В данном случае, насколько я понимаю, узкое место — нехватка процессора. При замеренном сжатии в 5.5 раз если сеть нагружена не более, чем на 100/5.5≈18%, то передача несжатых данных может дать прирост.

[Bizdelnick]

есть ли архивация быстрее gzip в линуксе

pigz?

[azsx]

благодаря слову pigz нашел сравнение, которое мне интересно...
Обсуждение архиваторов

насколько я понимаю, узкое место — нехватка процессора. При замеренном сжатии в 5.5 раз если сеть нагружена не более, чем на 100/5.5≈18%, то передача несжатых данных может дать прирост.

я конечно не знаю почему, но мне кажется, что у меня скорее тормозит винт, а не проц. Хотя доказать я этого не могу.

[DaemonTux]

Почему бы не посмотреть показатели i/o

[drBatty]

Как обычно, надо искать узкое место. В данном случае, насколько я понимаю, узкое место — нехватка процессора.

а я думаю, что без сжатия tar жрёт 0.5% CPU, а со сжатием будет жрать 1%. Что никак не скажется на его производительности. Вопрос не в том, где узкое место, а в том, хватает его или нет. ИМХО в случае ТС - хватает, и скорость упирается в чтение и запись. Т.к. это конкурирующие и не распараллелимые процессы, то ускорение одного из них прибавит скорость. ТС пишет, что его файлы хорошо жмутся.

сжатие в 5,5 раз

т.е. скорость записи возрастёт в 5.5 раз. И если скорость записи и скорость чтения грубо принять одинаковой, то общая скорость дисковых операций возрастёт в 2/(1+0.2) = 1.(6) раз. Ну а само сжатие выполняется параллельно с чтением/записью, и, ИМХО CPU успеет всё обсчитать.

Для ТС - просто попробуйте. tar -c vs tar -cz

[watashiwa_daredeska]

т.е. скорость записи возрастёт в 5.5 раз

А там что, еще и локальная запись? Насколько я понял, архив льется по сети на другую машину, и тормозит совсем не та другая, а эта, на которой происходит чтение и сжатие, но не запись.

[azsx]

Для ТС - просто попробуйте. tar -c vs tar -cz

обязательно попробую. Я тама чуть чуть ошибся, теперь удаляю 850 тысяч пустых файлов. Потом освобожусь - попробую разные параметры архивации, правда зачем мне архивация без сжатия?

А там что, еще и локальная запись? Насколько я понял, архив льется по сети на другую машину, и тормозит совсем не та другая, а эта, на которой происходит чтение и сжатие, но не запись.

На локальной машине сперва создаю архив, а потом копирую его на другой комп.

[watashiwa_daredeska]

На локальной машине сперва создаю архив, а потом копирую его на другой комп.

А зачем? Особенно, если есть подозрение в нагруженности дисковой подсистемы?

[drBatty]

А зачем? Особенно, если есть подозрение в нагруженности дисковой подсистемы?

ну видимо раньше это было удобно и надёжно - иметь локальную копию бекапа. Сейчас стало не удобно, файлов больше.

зачем мне архивация без сжатия?

потому-что создавать файлы - тоже время отнимает. И довольно много, если в одном каталоге много файлов. Намного быстрее создать один файл.
И да, передать 850000 файлов тоже намного дольше, чем один тарбол.

[Jonnywalker]

Попробуйте rdiff-backup.
Он использует для передачи данных библиотеки rsync и ssh.
Бэкап инкрементный. В точке назначения вы всегда имеете актуальное состояние исходной папки и всю историю изменений, позволяющую восстновить более ранние состояния (не забывайте своевременно выносить старые инкременты).