| Скорость 2.6.20.ovz в VirtualBox [message #12257] |
Mon, 23 April 2007 09:27  |
|
|
Решил завести отдельную тему из сообщения http://forum.openvz.org/index.php?t=tree&th=2388&mid =12238&&rev=&reveal=
Повторное изложение проблемы: известно (из документации VirtualBox), что ядра 2.6.17 и 2.6.18 выполняются внутри VirtaulBox медленнее, чем 2.6.19+ (и могут даже трапаться). Проверка скорости выполнения внутри VIrtualBox гентушных ядер показала, что это правда: система с ядром 2.6.20 грузится быстрее, чем с ядром 2.6.18. Изменеия в скорости выполнения отлавливаются и nbench тестом.
Запуск бинарников 2.6.20-ovz002 (с сайта) внутри VirtaulBox показал, что и эта (уже openvz) версия ядра 2.6.20 работает быстрее ядра 2.6.18 (скорость выполнения одинакова для openvz и обычного варианта ядра). А вот скорость выполнения 2.6.20-ovz005 хоть по nbech тесту вроде существенно не изменилась, но загрузка системы (выполнеие скриптов) жутко замедлилась.
Сейчас пытаюсь определить, какой именно патч привел к тормозам...
PS: а где это берется тест, о котором в http://forum.openvz.org/index.php?t=tree&th=2340&sta rt=0& идет речь
|
|
|
|
|
|
| Re: Скорость 2.6.20.ovz в VirtualBox [message #12278 is a reply to message #12258] |
Tue, 24 April 2007 06:51  |
|
|
Взял, попробовал внутри VirtualBox 1.3.8 -- не работает (все по нулям). Видимо из-за того, что время внутри VirtualBox движется странно. Например время компиляции ядра по time таково: (real+user)=sys (на реальном железе имеем real=(user+sys)). Если судить по коментам в репозитарии, то в следующей версии VirtaulBox время будет считаться нормально.
Теперь к вопросу о скорости... Был неправ, что по nbench результаты существенно не отличаются.
BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Для версии ovz002:
INTEGER INDEX : 18.482
FLOATING-POINT INDEX: 12.498
Для версии ovz003:
INTEGER INDEX : 13.131
FLOATING-POINT INDEX: 9.737
Показатели стабильно хуже на 25%
Путем git bisect нашелся патч, который тормозит. Это c4eff5898dee116fc410cc543cae074c21c818ba
[BC] Call bc_findcreate_cfq_bc() out of q->queue_lock
Otherwise we may cause GFP_KERNEL allocation to happen
with a spinlock held.
Чем именно он умудряется добиться такого результата -- мне не ведомо. Может возможны какие-либо другие варианты этого патча?
PS: ядро ovz002 с патчем
git diff ovz002 35c2a19f85bd5a7878fb9a8f6cb6d65ad1e6716e
(Limit setluid caps in VE as in 2.6.9, первое деление ovz002to003 пополам)
стабильно трапается как в VirtualBox, так и на реальном железе.
|
|
|
|
|
|
| Re: Скорость 2.6.20.ovz в VirtualBox [message #12296 is a reply to message #12286] |
Tue, 24 April 2007 13:48 |
|
|
Боюсь, что такого уменьшения скорости на чистом жедезе (однопроцессорная система) нет. Иначе бы это уже заметили. Я читал, что в английском форуме ругались на пониженную производительность openvz в мультипроцессорной системе. Причины могут быть похожи.
Под VirtualBox: замедление из-за увеличения числа дорогих для эмуляции операций (необходимости переключаться на гипервизор и эмулировать выполнение команд).
На многопроцессорной системе: увеличение числа операций по синхронизации кэшей процессоров (например).
PS: Ведь теоретически скорость выполнения арифметических операций под VirtualBox и на голом железе отличаться не должна. А она меньше на четверть даже в лучшем случае (INTEGER INDEX на реальном железе: 25, FLOATING-POINT INDEX: 18.080)
|
|
|
|
| Re: Скорость 2.6.20.ovz в VirtualBox [message #12305 is a reply to message #12257] |
Tue, 24 April 2007 15:33 |
Alexandr Andreev
Messages: 35
Registered: October 2006
|
Member |
|
|
| Quote: |
Под VirtualBox: замедление из-за увеличения числа дорогих для эмуляции операций (необходимости переключаться на гипервизор и эмулировать выполнение команд).
|
А нет ли где у VirtualBox логов, чтобы посмотреть сколько времени выполнялся native код, а сколько было потрачено на эмуляцию? Или хотя бы что там типа количества проэмулированных инструкций из группы "emulating guest code" http://www.virtualbox.org/wiki/VirtualBox_architecture
| Quote: |
Боюсь, что такого уменьшения скорости на чистом железе (однопроцессорная система) нет.
|
действительно нет. Я сравнил ovz2 vs ovz3 на 16-ти процессорном хосте
ovz2 16 CPU's
INTEGER INDEX : 59.258
FLOATING-POINT INDEX: 34.961
ovz3 16 CPU's
INTEGER INDEX : 59.243
FLOATING-POINT INDEX: 35.017
ovz3 1 CPU (i.e. maxcpus=1)
INTEGER INDEX : 60.829
FLOATING-POINT INDEX: 35.118
ядро ovz2 было пропатчено, чтобы не было 'Kernel panic' в cfq_dispatch...
| Quote: |
Я читал, что в английском форуме ругались на пониженную производительность openvz в мультипроцессорной системе. Причины могут быть похожи.
|
Там проблемы совсем в другом месте - есть разница между оригинальным ядром и ovz ядром на __некоторых__ тестах в SMP системе с большим кол-вом процессоров, причем это не вычислительные тесты как в данном случае.
Раз это замедление проявляется и на стандартных ядрах, и тем более раз VirtualBox уже обо всём в курсе, то я думаю стоит подождать обновлений VirtualBox.
А вообще производительность ядер имеет смысл сравнивать только на реальном железе (причем лучше на простом, а не на каком-нибудь хитроумном IA64), иначе непонятно что значат все эти цифры.
[Updated on: Tue, 24 April 2007 15:45] Report message to a moderator |
|
|
|
| Re: Скорость 2.6.20.ovz в VirtualBox [message #12312 is a reply to message #12305] |
Tue, 24 April 2007 18:43 |
|
|
| Quote: |
А нет ли где у VirtualBox логов, чтобы посмотреть сколько времени выполнялся native код, а сколько было потрачено на эмуляцию?
|
Ребята моляат как партизаны относительно техники эмуляции и что конкретно вызывает тормоза (например что сломали в 2.6.17-2.6.18 ядрах). А лазить по исходникам еще не пробовал. Но если сравнить данные о VMKNOPPIX http://unit.aist.go.jp/itri/knoppix/vmknoppix/index-en.html, то выводы таковы:
xen domU на вычислениии pi работает со скоростью чистого железа
VirtualBox на том же тесте теряет 25% от скорости чистого железа и это нормально
А вот терять еще 25% из-за использования openvz-ядра внутри VirtaulBox не очень хочется.
Испралять команда VirtualBox, кроме вывода команды time (соотношение real, user, system) ничего пока не собираются. Их форум организован очень плохо, changelog изменений их репозитария как отдельная сущность отсутствует.
Наверно придется посмотреть исходники VirtualBox на предмет статистики (скорей действительно уже что-то есть). А еще лучше пока подождать 
PS: Интресноая новость из http://www.linux.org.ru/view-message.jsp?msgid=1893630
Из материалов выходит, что VMWare будет поддерживать паравиртуализацию, а вот VirtualBox молчит
PPS: Кстати, хотя в репозитарии XEN работают с 2.6.18 ядром, в 2.6.21-mm ветку уже пытаются залить xen. Так что от тестирования openvz под XEN лучше долго не отмахиваться.
Я сегодня сумел собрать xen-версию 2.6.18-6-el5-028.030 с openvz на борту, но запускать еще не пробовал. Хочется вместо патча openvz для rhel5 наложить таковой от чистого openvz (чтоб уж точно не было различий)
openvz и xen определили разные структуры с одним именем vcpu_info. А еще куча не примененых для архитектуры XEN изменений openvz (нет экспорта имен, отсутствует переименование)
Мечтается, что от XEN в openvz все же как-то переползет виртуал фрейм-буфер (девайс то уже в исходниках присутствует -- drivers/xen/fbfront)
Кстати только сегодня узнал, что существует такой AmazonC2, на котором отрабатывают аналоги MapReduce http://lucene.apache.org/nutch/about.html, и что указанный AmazonC2 использует XEN для реализации сервиса виртуальных машин.
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Скорость 2.6.20.ovz в VirtualBox [message #12372 is a reply to message #12328] |
Thu, 26 April 2007 01:45 |
|
|
| Quote: |
Так всё-таки из за openvz-ядра, или просто из-за 2.6.20? Насколько я вижу разницы между openvz 2.6.20 и rhel5 2.6.18 в этом тесте вообще нет на реальном железе
|
Про реальное железо немного потом...
А внутри VirtualBox 2.6.20 быстрее бегает, чем 2.6.18. И ovz002.1 бегала с такой же скорость как и чистый 2.6.20.
И скорость выполнения ovz002.1 сильно провалилась после второго патча в цепочке ovz002.1 -> ovz003 (проверял). Однако и дальнейшие патчи как-то влияли на скорость, только отследить их влияние было уже трудно. nbench вначале говорил на многих тестах, что не гарантируется 95% достоверность, ибо результаты не стабильны (плавают). А потом все замедлилось стабильно. Я пробовал ovz003 с отбитым назад проблемным патчем. Результаты не улучшились.
|
|
|
|
| Re: Скорость 2.6.20.ovz в VirtualBox [message #12374 is a reply to message #12331] |
Thu, 26 April 2007 04:09 |
|
|
| dev wrote on Wed, 25 April 2007 04:47 |
если вы уже проделали какую-то часть работы по скрещиванию Xen и OpenVZ в 2.6.18-RHEL5 ядрах, ты мы с удовольствием примем патчи и помощь. Мы не отмахиваемся, просто идей и задач у нас много, а все сделать сразу или спустя рукава не можем и не хотим :@)))
|
http://89.19.167.91/fantoo/openvzelx-src.tgz
http://89.19.167.91/fantoo/openvzelx-bin.tgz
Второе -- это уже скомпиленное ядро и модули вместе с конфигом для grub.
Первое -- гентушные ebuild (вместе со всеми дополнительными патчами) для установки исходиков ядра и сборки RedHat xen-монитора.
Ebuild сильно похожи на spec по структуре и содержат перечень налагаемых на стандартное ядро патчей. Конфиг для сборки ядра там же. Это openvz-конфиг для rhel5, там только:
- установлена субархитектура XEN
- добавлен пункт dom0 (он по умолчанию выключен)
- Frequency Scaling выключен (XEN это не переваривает, да и powernow-k8.c не собирается)
- все графические драйверы вместо M превращены в * (vesa драйвер для XEN включать нельзя) и добавлен драйвер radeon
На первый взляд все работает без проблем и VM запускаются. Но тестировать пока времени не было (да и не спец я по openvz). Наверно все же требуется какая-то серьезная проверка. Запуск XEN машин тоже не проверялся.
|
|
|
|
| Re: Скорость 2.6.20.ovz в VirtualBox [message #12376 is a reply to message #12329] |
Thu, 26 April 2007 05:30 |
|
|
| dev wrote on Wed, 25 April 2007 04:42 |
самое странное и подозрительное что данный патч не имеет вообще никакого отношения к CPU )) максимум он влияет на disk I/O...
поэтому мы тут удивлены и не знаем что делать :@)))
может вы где-то ошиблись при делении? или вы перепроверили несколько раз что откат/накат патча меняет performance?
|
Отличная скорость disk и net I/O -- изюминка VirtualBox Так что влияние на скорость DISK I/O запросто могло повлиять на ... 
Если бы тест не прерывался ядром во время выполнения (диспетчеризация) и не было бы обращений к ядру за сервисом, то и результаты были бы как на реальном железе. Однако VirtualBox умудряется выполнять вычисления (тесты) на 25% медленнее и без помощи openvz. И не только конкретно nbench тест.
Результат проверялся и перепроверялся, вроде ошибки быть не должно. Но целью скорей было выяснить, что именно может ухудшать показатели VirtualBox. Ибо скорость выполнения и стандарных ядер внутри VirtualBox сильно разнится.
Вывод: В общем, не стоит пока на VirtualBox обращать внимания. Не зря видно rPath http://www.rpath.com/rbuilder/ создает образы для qemu, VMWare, VirtualPC и не упоминает про VirtualBox.
PS: были попытки обращения к команде VirtualBox за помощью или хоть подсказкой (через forum и mail-лист), но у них пока в плане ответов плоховато.
|
|
|
|
|
|
OpenVZ Forum
Members
Search
Help
Register
Login
Home
