У нас возникла неприятная проблема с производительностью при запуске нашего многопоточного программного обеспечения для рендеринга внутри виртуальной машины.
Мы запускаем Kubuntu 12.04 в VirtualBox 4.0.10_Debianr72436, который работает headless на вычислительном сервере Debian (6.0.6, 2.6.32-5-amd64). Он имеет 2*6 ядерный процессор Intel Xeon X5660 с гиперпоточностью и около 64 ГБ оперативной памяти. Мы подключаемся к виртуальной машине через TigerVNC Viewer для X версии 1.1.0. Виртуальная машина в настоящее время настроена на использование всех 24 ядер, но описанные ниже проблемы могут наблюдаться, когда она настроена на меньшее количество ядер (например, 12).
Проблема:
Когда мы запускаем наш рендерер всего с одним потоком рендеринга, он работает со скоростью, сравнимой с той, которую мы получаем при запуске напрямую на metal на других машинах (Intel Core 2 Duo MacBook). Однако, по мере увеличения количества рабочих потоков, он ускоряется лишь незначительно (довольно далеко от 1/n), а при количестве потоков около 5 он начинает фактически замедляться. От 8 потоков и более он становится даже медленнее, чем однопоточное приложение. Когда рендерер запускается напрямую на metal на наших MacBook, проблем не возникает, независимо от того, сколько потоков вы указываете для запуска. Например, 16 потоков на двухъядерном процессоре работают так же быстро, как и двухпоточный экземпляр.
Затем мы попытались запустить несколько однопоточных экземпляров нашего рендерера параллельно с удивительным результатом. Когда мы запускаем 4 экземпляра, все в порядке — они работают с такой же скоростью, как один экземпляр, но когда мы запускаем 6 экземпляров, все они замедляются примерно на 50%!
Мы также попробовали запустить другой рендерер (pbrt v.2), чтобы проверить, как справляются другие и были ли их результаты лучше. Он хорошо масштабировался до 13 потоков, но затем тоже замедлился (но не так сильно, как наше программное обеспечение).
Наш рендерер написан на Objective C в сочетании с C и битами ассемблера. Мы используем операции XADD и CAS в нашем коде для доступа к общим данным. Есть сильное подозрение, что эти два могут быть источником наших проблем. Есть идеи по этому поводу?
Кстати: мы не можем установить среду выполнения Obj-C и другие необходимые библиотеки и запустить наше программное обеспечение непосредственно на железе из-за политики сервера.
Фрагмент конфигурации виртуальной машины:
- Объем памяти: 4000 МБ
- Слияние страниц: выкл.
- Размер видеопамяти: 12 МБ
- HPET: выкл.
- Чипсет: piix3
- Прошивка: BIOS
- Количество ЦП: 24
- Синтетический ЦП: выкл.
- Переопределения CPUID: нет
- ACPI: включен
- IOAPIC: на
- PAE: выкл.
- Смещение по времени: 0 мс
- RTC: UTC
- Аппаратный виртуальный внешний: вкл.
- Hardw. virt.ext эксклюзив: выкл.
- Вложенная пагинация: вкл.
- Большие страницы: вкл.
- VT-x VPID: вкл.
- 3D-ускорение: выкл.
- Ускорение 2D-видео: выкл.
- Уровень выполнения дополнений: 2
- Настроенный размер области памяти: 0 МБ
решение1
Я тут пишу, но... В графическом интерфейсе щелкните правой кнопкой мыши на экземпляре Kubuntu и выберите «Настройки», пока он не запущен. Проверьте, ограничен ли там ваш ЦП. Вероятно, вы захотите посмотреть, как ваша система отреагирует на выбор 20 или 22 ЦП вместо 24, чтобы смягчить конкуренцию за ресурсы между виртуальным и хостовым компьютером. Затем попробуйте запустить один экземпляр с 20 потоками. Я бы ожидал увидеть скачок ЦП на машине для 20 ядер, а оставшиеся 4 также увеличатся до 100%, пытаясь не отставать. Есть ли у вас другие приложения, работающие на этой машине, помимо вашей виртуальной машины?