Home » International » Russian » скорость ovz и чистых ядер на реальном железе
скорость ovz и чистых ядер на реальном железе [message #12373] |
Thu, 26 April 2007 02:44 ![Go to next message Go to next message](/theme/ovz3/images/down.png) |
|
Quote: | Так всё-таки из за openvz-ядра, или просто из-за 2.6.20? Насколько я вижу разницы между openvz 2.6.20 и rhel5 2.6.18 в этом тесте вообще нет на реальном железе
|
Да, отложим в сторону туманный вопрос по скорость в VirtualBox и прочих хитрых эмуляторах...
Теперь про скорость на реальном железе...
nbech здесь действительно показывает одинаковые результаты. И было бы странно видеть другое на арифметическом тесте.
Однако заинтересовавшись темой, решил добить ее до конца и проверить на реальном железе показатели чистого и openvz ядер по unixbench wht тесту. Странно, но у меня получились показатели, что и у http://forum.openvz.org/index.php?t=tree&goto=11964& #msg_11964 И уже на обычной машине: Intel(R) Celeron(R) CPU 1.70GHz (cpu family 15, model 1, stepping 3) с обычным PATA 120 Гиг без RAID, RAM 512 Мег, gcc 3.4.6, glibc 2.3.6
Результирующие показатели (FINAL SCORE):
2.6.20-gentoo-r6 70,7
2.6.20-openvz20-002.1 54,9
2.6.20-openvz20-005.1 53,1
2.6.18-openvzel-028.030 54,3
2.6.18-openvzelx-028.030-rc1 43,5
Последняя строчка -- это openvz под xen (тест для xen без openvz на подходе). Окончаение EL означает наличие патчей RHEL5
Как видно, разница между чистым и openvz вариантами налицо. А странно то, что у команды openvz воспроизвести результаты не получается: в теме про VirtualBox была реплика, что известие англичанина относится к экзотическому железу и в реальной жизни места не имеет.
|
|
|
Re: скорость ovz и чистых ядер на реальном железе [message #12378 is a reply to message #12373] |
Thu, 26 April 2007 06:26 ![Go to previous message Go to previous message](/theme/ovz3/images/up.png) ![Go to next message Go to next message](/theme/ovz3/images/down.png) |
|
Таблица с добавленной строчкой 2.6.18-elx (RHEL5 без openvz патчей под XEN)
2.6.20-gentoo-r6 70,7
2.6.20-openvz20-002.1 54,9
2.6.20-openvz20-005.1 53,1
2.6.18-openvzel-028.030 54,3
2.6.18-elx 46.3
2.6.18-openvzelx-028.030-rc1 43,5
Теперь на все претензии к openvz можно просить прокоментировать указанную таблицу...
PS: чем команда XEN меряет производительность своего ядра?
|
|
|
|
Re: скорость ovz и чистых ядер на реальном железе [message #12405 is a reply to message #12373] |
Fri, 27 April 2007 10:45 ![Go to previous message Go to previous message](/theme/ovz3/images/up.png) ![Go to next message Go to next message](/theme/ovz3/images/down.png) |
Alexandr Andreev
Messages: 35 Registered: October 2006
|
Member |
|
|
Quote: | Как видно, разница между чистым и openvz вариантами налицо. А странно то, что у команды openvz воспроизвести результаты не получается: в теме про VirtualBox была реплика, что известие англичанина относится к экзотическому железу и в реальной жизни места не имеет.
|
ничего странного. Все действительно зависит от:
а) конфигурации хоста (в частности CPU, memory).
б) конфигурации и версии ядра.
Только если мы хотим что-то полезное сделать, давайте договоримся о том, что мы должны пострадать немного паранойей:
(1) все ядра пересобираем из исходников прежде чем их тестировать, чтобы исключить возможность влияния компилятора. Неплохо убедиться, что ключи у компилятора будут везде одинаковыми.
(2) тесты запускаем загрузившись в runlevel 1, сеть должна быть естественно опущена. Никаких демонов запущено не должно быть. Я уж молчу про всякие VE.
(3) Ядра должны быть одного "типа", скажем во всех должна быть поддержка SMP - как самый распространенный случай.
(4) При запуске тестов неплохо убедится в том, что тест показывает стабильный результат. Т.е. тесты надо пускать раза по 3. Если результат будет нестабильным, то это также надо фиксировать.
(5) Желательно добавить в список ядер mainstream ядро (vanilla), которое берется за основу для ovz ядер. это важно, т.к. gentoo ядро может быть каким либо образом соптимизировано.
Без этих требований, приведенная таблица будет лишена реального смысла.
----------------------------
Выкладывайте:
а) полные результаты тестов
б) конфиги ядер.
посмотрим что к чему.
P.S> Сразу хочу сказать, что возможно в ближайшем будущем ожидаются обновления для ovz ядра как раз в плане производительности. Так что возможно придется потом перезапустить тесты на ovz ядрах.
|
|
|
Re: скорость ovz и чистых ядер на реальном железе [message #12423 is a reply to message #12405] |
Fri, 27 April 2007 16:14 ![Go to previous message Go to previous message](/theme/ovz3/images/up.png) ![Go to next message Go to next message](/theme/ovz3/images/down.png) |
|
Интересно, но в GENTOO все перечисленные условия выполняются -- готового нет, сборка в одних условиях, конфиги брались от RHEL5 (за исключением 2.6.20-openvz20-xxx -- там ваш конфиг для ускорения сборки), запуск по два раза (без иксов , но интернет был доступен, на машине никаких работ во время теста), gentoo-ядра от vanila отличаются только добавленим фишек типа vesa-tng, squashfs, fbspalsh и никаким тюнингом не страдают.
Кроме того, английский товарищ утверждал, что у него такие результаты на разных версиях openvz и железа.
Однако стоит ли доверять тесту, если XEN (без OPENVZ) просаживает его сильнее, чем OPENVZ? Скорее всего -- это влияние дополнительных планировщиков.
PS: Вот полные результаты (и конфиги):
http://89.19.167.91/fantoo/TEST-INFO.tgz
|
|
|
|
|
|
Re: скорость ovz и чистых ядер на реальном железе [message #12605 is a reply to message #12578] |
Fri, 04 May 2007 04:47 ![Go to previous message Go to previous message](/theme/ovz3/images/up.png) ![Go to next message Go to next message](/theme/ovz3/images/down.png) |
|
Alexandr Andreev wrote on Thu, 03 May 2007 05:07 | Не могли бы вы повторить измерения на OpenVZ ядре, пересобрав его с CONFIG_BEANCOUNTERS=n ,скорее всего проблема в "учете ресурсов".
|
Это теперь через неделю наверно... В попытке понять, как запускать domU в XEN порушил систему и сейчас собираю заново...
Результат.
В общем, нужены и xen-tools от RedHat (иначе несовместимость версий), и желательно glibc (что-то там с ld-linux.so.2 изменили в целях оптимизации для XEN). И после всего еще ошибка argument error (22). Что означает domU и dom0 не совпадают по PAE. Лучше всего пересобрать RedHat-ядро без PAE. Ибо и NetBSD domU, и rPath domU пока без PAE. Хотя есть процедура по замене в линуксовых domU-IMG ядра на таковое от RedHat.
А так ядро RHEL5-OVZ-XEN похоже нормально работает во всех аспектах. Только грузится оно на глаз медленнее чем ядро RHEL5-OVZ.
RedHat вроде выпустила новую версию ядра (с исправлениями). Это если вы готовите новую версию RHEL5-OVZ... А для RHEL5-OVZ-XEN в конфиге неплохо в графе XEN установить галочки как у RedHat (там у них много драйверов в виде модулей). Иначе /etc/rc.d/init.d/xend пытается грузить модули и ругается.
Quote: | Странно то, что на наших машинах эта фича влияет (причем естественным образом) на результаты только части тестов (execl, shell), а у вас, насколько я вижу, overhead есть почти на всех тестах.
|
Да, попробую почетче тестировать (без демонов и интернета).
|
|
|
Re: скорость ovz и чистых ядер на реальном железе [message #12606 is a reply to message #12373] |
Fri, 04 May 2007 06:47 ![Go to previous message Go to previous message](/theme/ovz3/images/up.png) ![Go to next message Go to next message](/theme/ovz3/images/down.png) |
dev
Messages: 1693 Registered: September 2005 Location: Moscow
|
Senior Member |
![5072133](/theme/ovz3/images/icq.png)
|
|
seyko2 wrote on Thu, 26 April 2007 06:44 |
Однако заинтересовавшись темой, решил добить ее до конца и проверить на реальном железе показатели чистого и openvz ядер по unixbench wht тесту. Странно, но у меня получились показатели, что и у http://forum.openvz.org/index.php?t=tree&goto=11964& #msg_11964 И уже на обычной машине: Intel(R) Celeron(R) CPU 1.70GHz (cpu family 15, model 1, stepping 3) с обычным PATA 120 Гиг без RAID, RAM 512 Мег, gcc 3.4.6, glibc 2.3.6
Результирующие показатели (FINAL SCORE):
2.6.20-gentoo-r6 70,7
2.6.20-openvz20-002.1 54,9
2.6.20-openvz20-005.1 53,1
2.6.18-openvzel-028.030 54,3
2.6.18-openvzelx-028.030-rc1 43,5
Как видно, разница между чистым и openvz вариантами налицо. А странно то, что у команды openvz воспроизвести результаты не получается: в теме про VirtualBox была реплика, что известие англичанина относится к экзотическому железу и в реальной жизни места не имеет.
|
Мы в курсе что проседают тесты на execl и process creation. Это происходит неизбежно т.к. эти операции тяжелые в плане слежения за респределением ресурсов памяти. Иными словами на них влияет ресурс менеджмент. Если проседает что-то еще, нужно обязательно разбираться. От себя лишь добавлю что это микробенчмарка, да, она меряет некоторые базовые вызовы, но все же это слабо влияет на производительность реальных серверов/приложений, т.к. никто слава богу не делает бесконечный fork() или exec(). apache делает pre-fork и т.д.
Что меня здесь удивляет, так это действительно неповторимость этих тестов у нас. На наших машинах эти два теста тоже проседают, но оптимизации в шедулере позволяют отыграть SCOREs на других тестах...
В принципе оба теста можно починить, если мерять память в попугаях и не учитывать шаредные страницы памяти :@)
|
|
|
|
|
Re: скорость ovz и чистых ядер на реальном железе [message #12736 is a reply to message #12610] |
Tue, 08 May 2007 11:59 ![Go to previous message Go to previous message](/theme/ovz3/images/up.png) ![Go to next message Go to next message](/theme/ovz3/images/down.png) |
|
Quote: | Мне почему-то кажется что нужно писать свой драйвер к VT, который бы эмулировал железо и хранил экраны с данными, плюс к которому был бы способ подключить backend.
|
Вроде в XEN (как и в L4Linux под L4, http://os.inf.tu-dresden.de/L4/LinuxOnL4/ -- это откуда основатель XEN пришел) именно так и сделано. Имеют свой FRAMEBUFFER-driver, который по большому счету только и делает, что хранит вывод в буфере и передает удаленному VNC-серверу(или клиенту?) при запросе. Какая проблема с реализацией этого для OPENVZ? HM не трогаем. Вроде все должно получиться и работать одинаково как для XEN domU, так и для OPENVZ VM.
|
|
|
|
|
Goto Forum:
Current Time: Sun Aug 25 09:18:50 GMT 2024
Total time taken to generate the page: 0.03471 seconds
|