Операция создания контейнера - разовая. Поэтому, если время их создания не
устраивает, то их можно создавать и на более быстрой машине.

Точнее, не контейнера, а кэша пакетов для заготовок контейнеров.

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

Использовать для этого другую машину предлагать нельзя - в 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.