Довольно простой template (и контейнер на его базе) создаётся непомерно долго. на PII400 это происходит в течении часа. Вся проблема в tar|gzip и дальнейшем gzip|tar Это очень критично. Ускорить явно можно отключив не нужный gzip -9
Операция создания контейнера - разовая. Поэтому, если время их создания не устраивает, то их можно создавать и на более быстрой машине.
Точнее, не контейнера, а кэша пакетов для заготовок контейнеров.
Эта разовая операция занимает настолько много времени, что продукт становится неюзабельным. Использовать для этого другую машину предлагать нельзя - в WEB интерфейсе нет возможности загрузить темплейт с другой машины. Я собственно не вижу причин для того, что бы избавится от gzip -9. Или жалко свободное место на диске ? Так сделай галочку - сжимать контейнер или нет.
Кстати, да -- галка-сжималка позволила бы не идти на компромисс между диском и процессором заранее. Но вообще час не должен смущать владельца PII в наши дни. 2 rider: я порой тестирую на 3000+ с подсунутым ноутбучным 1.6Gb ;-)
В серверном дистрибутиве - смущает безусловно. К тому же понятно как это можно значительно ускорить (на мой взгляд - раза в четыре)
Что с этой ошибкой ? Будет исправляться ?
Ускорить можно в двух местах: + перевести сборку на tmpfs (alterator-ovz) + выключить сжатие template cache (vzctl,alterator-ovz) В скобках указаны пакеты, которые нужно для этого модифицировать.
На tmpfs желательно опционально - не на всех серверах много памяти. А использование swop ускорит незначительно (если не замедлит). Достаточно просто отключить сжатие - это самый болезненный участок.
Может, экспортировать (регулируемую) переменную среды GZIP? GZIP=-0 как раз и сделает "без сжатия", а -1 должно и пожать быстро, и всё-таки хоть несколько размер снизить.
На стороне alterator-ovz приём несжатых gzip'ом тарболов была добавлена в 0.4-alt1. Осталось реализовать приём несжатых gzip'ом тарболов в vzctl, после чего можно будет отключать сжатие.
Не надо понижать Severety.
(In reply to comment #10) > Осталось реализовать приём несжатых gzip'ом тарболов в vzctl, после чего можно > будет отключать сжатие. Это сложно? Если важно для Server 4.0.2 и никто не доберётся до vzctl, можно хотя бы GZIP=-1 (-0 не работает -- откуда его взял...) всунуть в vecache из ve-build-scripts. Только прямщас это не сработает -- в spt гвоздями прибито -f9.
(In reply to comment #12) > (In reply to comment #10) > > Осталось реализовать приём несжатых gzip'ом тарболов в vzctl, после чего можно > > будет отключать сжатие. > Это сложно? Это реализовано в vzctl-3.0.18-44-g241736e
(In reply to comment #13) > Это реализовано в vzctl-3.0.18-44-g241736e Тогда можно NMU/ACL на ve-build-scripts? (spt можно оставить как есть, хотя хранение с небольшой степенью сжатия IMHO полезно -- "единичка" достаточно быстрая и на PII, но всё равно место экономит; если это желательно, то нужно ещё NMU на spt)
для сравнения: .tar 56M/1:47, .tar.gz 24M/1:43 (-1)
у меня в git (mike/11343): * Tue Jan 29 2008 Michael Shigorin <mike@altlinux> 0.0.2-alt1.1 - implemented compression level support (requires spt >= 0.6.0-alt10.2.1), image type choice (requires spt >= 0.6.0-alt10); fixes #11343 - default gzip compression level set to 6 (gzip default overridden in spt) Проверено, работает.
Также задействовано в alterator-ovz-0.4-alt6.1 (у меня в git, mike/11343). Зависимости расставлены так, чтобы добавленную ручку обеспечить поддержкой; заливать надо сразу: spt-0.6.0-alt10.2.1 (lakostis) ve-build-scripts-0.0.2-alt1.2 (lakostis inger) alterator-ovz-0.4-alt6.1 (lakostis inger mike) Таким образом, предлагаю либо разобрать соответствующие ветки у меня в git тем, кто может влить, или выдать NMU. Хорошо бы alterator-ovz посмотрел Стас, а то я мержил его alt6 поверх своего alt5.1.1, потом добавлял в пакет выпавший из него после переноса ovz/html-messages.scm и опять make update-po; всё равно пока починить частично отъехавшую локализацию не выходит.
fixed in 0.0.2-alt2, хотя в моих тестах разница получалась в пределах ~10%. По умолчанию куда лучше GZIP=-1: и поджимает, и почти так же быстро, как просто tar.
