Уточню задачу - распаковать с минимальным потреблением ресурсов - пусть это будет даже долго, главное чтобы минимально грузило процессор. При этом упаковка не особо интересует - может быть и ресурсоемкой. Есть какой-то оптимальный выход?
LinuxForum.Fans
Вопрос по созданию zip-архива
Автор: valet
33 сообщений
6612 просмотров
valet,
операция распаковки в случае gzip/bzip2 по ресурсам -- это семечки в сравнении с записью распакованного на диск, всё упрётся в производительность дисковой подсистемы.
Сжатие поможет экономить а) ресурсы диска/время при записи/чтении запакованного или б) трафик/время при передаче по сети.
По поводу загрузки процессора -- есть nice/renice для понижения приоритета.
А в остальном, возьмите тестовый блок в несколько Gb да и проверьте, как оба/три/больше вариантов (включая rsync) поведут себя в ваших условиях.
всё упрётся в производительность дисковой подсистемы.
это конечно печально, подозреваю что в это я и не вписываюсь со своими 150 тысяч файлов.
б) трафик/время при передаче по сети.
это да - но этот вопрос меня абсолютно не интересует - согласен даже передать намного больше, если нужно. Да и экономия при сжатии там сомнительная так как это jpg-файлы.
а) ресурсы диска/время при записи/чтении запакованного
ну не знаю, насколько я понимаю - все равно же надо перед записью распаковать - на что потратятся пусть маленькие ресурсы, но потратятся, а записываться будет все равно в результате такого же размера файл - где экономия? Или я что-то не так понимаю?
есть nice/renice для понижения приоритета.
спасибо за наводку - буду гуглить...
Нашел способ для моего случая, запощу тут - может кому-то пригодится:
[console]nice -n 19 ionice -c 3 tar -xf images.tar[/console]
-n 19 - самый меньший проиритет (для процессора)
-с 3 - режим Idle для операций ввода/вывода (для диска)
И система будет работать отлично, так как мой tar будет использовать ресурсы так сказать бережно и только в том случае если другие процессы их не используют.
А кстати чистый nice без ionice не решает проблемы - ну это как я понял связано с тем, что тут говорили - сложность в дисковых операциях чтения/записи...
Всем спасибо за помощь. Особая благодарность bormant за наводку на nice.
мне сжимать вообще не надо, а bzip2 как я понял только сжимает. Поэтому вопрос выбора между tar и zip.
вы читать умете?
сжатие даёт увеличение скорости,
вы читать умете?
А вы? :)
Я кажется это тоже прокомментировал:
ну не знаю, насколько я понимаю - все равно же надо перед записью распаковать - на что потратятся пусть маленькие ресурсы, но потратятся, а записываться будет все равно в результате такого же размера файл - где экономия? Или я что-то не так понимаю?
Если мое утверждение верно, то сжатие никак не может давать увеличение скорости. Пусть будет очень незначительное уменьшение по скорости, но оно будет.
1. Распаковка сжатого содержимого: разжать и записать оригинал
2. Распаковки несжатого - только записать оригинал.
Как может быть увеличение в первом случае? Разве я не прав?
В общем случае сжатое/несжатое содержимое берутся из откуда-то. Экономия вот на этом "откуда-то" -- на чтении с диска, на приёме из сети.
Но поскольку ранее уже было сказано, что исходники в JPEG, то есть практически несжимаемые данные, то в этом контексте сжатие/распаковка ничего, кроме нагрузки на процессор, не даст.
ps. Хорошей иллюстрацией могла бы быть FIDO mailbomb -- практически нет затрат на передачу огромного файла, передать такого размера файл одним куском нереально (в то время).
bormant, сейчас для большинства fidonet непонятное что-то...
ну не знаю, насколько я понимаю - все равно же надо перед записью распаковать - на что потратятся пусть маленькие ресурсы, но потратятся, а записываться будет все равно в результате такого же размера файл - где экономия? Или я что-то не так понимаю?
Если мое утверждение верно, то сжатие никак не может давать увеличение скорости. Пусть будет очень незначительное уменьшение по скорости, но оно будет.
ваше утверждение верно, но только в том случае, если у вас информация сжимается из памяти в память. Если сжатие происходит на диск, то очевидно, что скорость создания архива в любом случае не выше скорости записи. В силу того, что запись с прошлого века производится НЕ процессором, то этот процессор очевидно будет простаивать. Т.е. мы можем его нагружать, причём довольно сильно. Ну а время записи прямо пропорционально размеру - запишем в 2 раза меньше == вдвое быстрее.
1. Распаковка сжатого содержимого: разжать и записать оригинал
ваша ошибка в том, что разжатие идёт потоком, т.е. непрерывно и одновременно с записью. Например bzip2 жмёт блоками в ~1Мб. Т.е. если ваш архив будет больше Мб, то разжатие будет осуществляться вместе с записью. А не перед нею.
newzenon, На самом деле такую гадость можно не только в FIDO сделать. Просто в FIDO это впервые(?) появилось. Суть:
1. создаём разрежённый файл из одних нулей скажем в 50Тб. Он у нас занимает на диске совсем немного.
2. добавляем его аттачем к письму.
3. по дороге он упаковывается
4. а у принимающей стороны распаковывается. Но уже не как разряжённый.
Эффект - система умирает, ибо нет места.
И все таки без сжатия быстрее распаковывается. Создал 5 относительно небольших tar'ов по 200 Мб в среднем и запустил распаковку - сделало за несколько секунд. Потом все удалил перепаковал с сжатием и запустил распаковку - делало несколько минут.
Так что это какие-то сказки что с сжатием быстрее распаковывается.
Создал 5 относительно небольших tar'ов по 200 Мб в среднем и запустил распаковку - сделало за несколько секунд. Потом все удалил перепаковал с сжатием и запустил распаковку - делало несколько минут.
Так что это какие-то сказки что с сжатием быстрее распаковывается.
это вы не воспринимаете смысл написанного. Речь шла о записи на HDD, а где у вас эта запись? А её и нету. Вы пишете в память, потому-что я уверен, что 200Мб свободных у вас есть. А на диск данные пишутся после завершения команды. И вы это уже не считаете. Вы разве не замечали, что сменные носители иногда долго "извлекаются"? Как раз потому, что записывается информация, которая якобы уже записана.
Речь шла о записи на HDD, а где у вас эта запись? А её и нету.
Вы к сожалению тут неправы. Нету там 200 Мб свободной памяти - ее там вообще свободной нету, это слабенький ВПС на котором крутится несколько гавносайтов на статике:
Вот скопировал с top'а
text
valet:/var/www# top
top - 16:24:03 up 82 days, 53 min, 2 users, load average: 0.00, 0.00, 0.00
Tasks: 46 total, 2 running, 44 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 204800k total, 204800k used, 0k free, 0k buffers
Swap: 0k total, 0k used, 0k free, 0k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1 root 18 0 8348 828 700 S 0.0 0.4 0:05.05 init
5382 root 15 0 71280 3816 2652 S 0.0 1.9 0:00.84 sshd
5679 root 15 0 12196 2400 1480 S 0.0 1.2 0:00.13 bash
8158 www-data 15 0 99016 5296 1180 S 0.0 2.6 0:10.87 nginx
11519 root 18 0 98800 6148 2700 S 0.0 3.0 0:00.10 nginx
11698 root 18 0 102m 4036 964 S 0.0 2.0 0:02.95 php5-fpm
11704 www-data 16 0 111m 12m 4528 S 0.0 6.1 3:34.75 php5-fpm
11705 www-data 16 0 110m 10m 4492 S 0.0 5.4 3:34.84 php5-fpm
11706 www-data 15 0 109m 10m 4468 S 0.0 5.2 3:35.44 php5-fpm
11707 www-data 15 0 111m 11m 4520 S 0.0 5.9 3:31.22 php5-fpm
11708 www-data 16 0 108m 9844 4532 S 0.0 4.8 3:36.68 php5-fpm
11709 www-data 16 0 110m 11m 4548 S 0.0 5.6 3:34.76 php5-fpm
11710 www-data 16 0 111m 11m 4504 S 0.0 5.9 3:32.56 php5-fpm
11711 www-data 16 0 111m 12m 4580 S 0.0 6.0 3:31.24 php5-fpm
11712 www-data 16 0 111m 12m 4556 S 0.0 6.1 3:35.06 php5-fpm
11713 www-data 16 0 111m 12m 4508 S 0.0 6.0 3:35.02 php5-fpm
11714 www-data 16 0 109m 10m 4484 S 0.0 5.2 3:34.68 php5-fpm
11716 www-data 16 0 111m 11m 4500 S 0.0 5.9 3:31.83 php5-fpm
11717 www-data 16 0 109m 10m 4484 S 0.0 5.2 3:35.96 php5-fpm
11718 www-data 16 0 109m 10m 4480 S 0.0 5.1 3:35.67 php5-fpm
11719 www-data 16 0 111m 11m 4496 S 0.0 6.0 3:32.77 php5-fpm
11722 www-data 16 0 111m 11m 4556 S 0.0 6.0 3:30.62 php5-fpm
11723 www-data 16 0 111m 11m 4480 S 0.0 5.9 3:30.21 php5-fpm
11724 www-data 16 0 108m 9816 4480 S 0.0 4.8 3:43.26 php5-fpm
11725 www-data 16 0 109m 10m 4464 S 0.0 5.2 3:35.27 php5-fpm
11726 www-data 16 0 111m 12m 4516 S 0.0 6.0 3:30.40 php5-fpm
11859 root 15 0 72556 5080 2640 R 0.0 2.5 0:00.36 sshd
12127 root 15 0 15840 6072 1480 S 0.0 3.0 0:00.49 bash
Обратите внимание: Mem: 204800k total, 204800k used - там всего несчастных 200 Мб памяти которая наглухо занята системой (причем стоит Debian squeeze), процессами php-fpm, nginx и т.д.
А на диск данные пишутся после завершения команды.
А разве не вы говорили что распаковка идет блоками по 1 МБ, которые пишутся сразу на диск потоково. Распаковался 1 Мб - записали и т.д.
ваша ошибка в том, что разжатие идёт потоком, т.е. непрерывно и одновременно с записью. Например bzip2 жмёт блоками в ~1Мб. Т.е. если ваш архив будет больше Мб, то разжатие будет осуществляться вместе с записью. А не перед нею.
Только я здесь вижу противоречия? :) Так как все таки - сначала распаковка (выполнение команды) и потом только запись на диск или параллельно...А на диск данные пишутся после завершения команды.
У меня такое впечатление, что меня хотят в чем-то подловить и найти подвох :) Я написал то, что заметил. Сначала я интересовался вопросом, потом разобрался и все расписал - мне нету смысла нарочно писать что-то не то. :)
Обратите внимание: Mem: 204800k total, 204800k used
вижу.
0k buffers
это намного хуже.
used оно у всех (почти) 100%. У меня <100% только на новых серверах, которые настраиваются/тестируются.
А разве не вы говорили что распаковка идет блоками по 1 МБ, которые пишутся сразу на диск потоково. Распаковался 1 Мб - записали и т.д.
с точки зрения архиватора - так и есть. На самом деле, система копирует инфу в buffers, и говорит "ОК". Это в нормальных ситуациях. У вас - НЕнормальная. У вас это не работает по причине отсутствия buffers.
Только я здесь вижу противоречия?
Это не противоречие, а оптимизация. Система всегда так делает, ибо быстрее (очевидно, когда сможет. У вас не смогла).
Так как все таки - сначала распаковка (выполнение команды) и потом только запись на диск или параллельно...
в случае вашего тупизма (не про вас лично, а про ОС, ничего не подумайте плохого), я даже не знаю что происходит. Единственное, что могу сказать точно - это всё в сотни раз медленнее, чем в обычных условиях.
У меня такое впечатление, что меня хотят в чем-то подловить и найти подвох
да, именно так. Подвох в том, что у вас вся память забита, потому-то она работает совсем не так, как должна работать.
вот что показывает free на первом-же попавшимся моём сервере:
[console]free
total used free shared buffers cached
Mem: 8 113 288 8 043 848 69 440 0 173296 3318688
-/+ buffers/cache: 4 551 864 3 561 424
Swap: 19 800 072 53312 19 746 760
[/console]
что касается дешёвых VPS'ок, я тут с огромным трудом там вообще поднял MySQL, и был злой как чёрт за такую адову работу. На следующий день заказчик взял нормальную систему, потому-как эта хоть и работала, но скорость была просто нулевая. Даже на 5-15 юзеров. Столько трудов потратил :(
Вы уж лучше купите на барахолке второй/третий пень, он даже на домашнем ADSL'е и то будет лучше работать. Честно.
Войдите или зарегистрируйтесь, чтобы ответить.
