Обнаружиласть в Server 4.0/4.0.1 проблема. Очень медленно работает RAID-контроллер. Например, форматирование раздела с такими параметрами Block size=4096 (log=2) Fragment size=4096 (log=2) 145965056 inodes, 291919115 blocks 14595955 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=4294967296 8909 block groups 32768 blocks per group, 32768 fragments per group 16384 inodes per group продолжается почти двое суток на незагруженной системе. Случайно обнаружил, что с не ovz ядром это происходит на порядок быстрее. При переписке с представителем SWsoft выявилось, что проблема в ядре ALt: пробовали ставить сборку 2.6.18-8.1.4.el5.028stab035.1 от SWsoft, с этим ядром проблема не воспроизводится.
Да, могу дать полный доступ на сервер.
To ovz maintainer.
На взятом у Михаила Шигорина 2.6.18-ovz-smp-alt13 тоже не воспроизводится.
Что происходит, если сменить IO scheduler - поставить вместо cfq anticipatory (или deadline)? echo -n anticipatory > /sys/block/sda/queue/scheduler
Точно. И с anticipatory, и с deadline проблемы нет. Меняю severity на normal.
На всякий случай засёк время для anticipatory и deadline. Отличие в секундах, форматировалось 1ч 14мин. C cfq было 43ч, минуты не помню.
Хм, что интересно, с 2.6.18-8.1.4.el5.028stab035.1 от SWsoft нормально работает и с cfq.
alt14 - это 028stab031; видимо, в 028stab035 cfq всё-таки починили.
Читая их анонсы -- со времён alt14 накопилось изрядно вроде бы фиксов довольно неприятных вещей...
> alt14 - это 028stab031; видимо, в 028stab035 cfq всё-таки починили. То есть, у нас с шедулерами ничего специального не делалось ?
с 2.6.18-8.el5.028stab031.1 воспроизвелось.
Konstantin Khorenko из SWsoft нашёл, где нужная разница между 028stab031 и 028stab035: http://git.openvz.org/?p=linux-2.6.18-openvz;a=commit;h=c7fa58b331d23c0796996dcab75c72053fafab5a
(In reply to comment #12) > Konstantin Khorenko из SWsoft нашёл, где нужная разница между 028stab031 и > 028stab035: > http://git.openvz.org/?p=linux-2.6.18-openvz;a=commit;h=c7fa58b331d23c0796996dcab75c72053fafab5a > У меня есть новая сборка ovz-smp на базе stab37. Выложить ее смогу только сегодня из офиса. Либо можете ее собрать самостоятельно из моего kernel-image-2.6.18 репозитория на git.alt (branch kernel-image-ovz-smp).
(In reply to comment #13) > У меня есть новая сборка ovz-smp на базе stab37. Выложить ее смогу только > сегодня из офиса. Давай, тоже прокачу на разном.
> kernel-image-2.6.18 репозитория на git.alt (branch kernel-image-ovz-smp). руки у меня пока до git не доходят. :-( Подожду.
(In reply to comment #13) > У меня есть новая сборка ovz-smp на базе stab37. Выложить ее смогу только > сегодня из офиса. Либо можете ее собрать самостоятельно из моего > kernel-image-2.6.18 репозитория на git.alt (branch kernel-image-ovz-smp). ftp.altlinux.ru/pub/people/lakostis/kernel-ovz/
Именно этого бага нет (ну, не удивительно :-) ). В остальном пока не знаю, но, вроде, работает, на первый взгляд.
кстати, stab38 готовится. Может, на него ориентироваться ?
ping (и в updates/4.0 это тоже нужно)
(In reply to comment #19) > ping (и в updates/4.0 это тоже нужно) мои трения изложены тут: http://lists.altlinux.org/pipermail/community/2007-October/396971.html смысл: другой контроллер - 3Ware 9550SE-4LP на апдейченом ядре ovz из updates для x86-64 дает жуть... пока пришлось съехать на std ядро, но хочется то ovz и контейнеров пачку! ё :(
На сколько я понимаю, в Бранче с 2.6.18-alt17 всё нормально в этом плане, закрываю.
