В Travis CI (http://travis-ci.org) мы используем виртуальные машины VirtualBox (через Vagrant) для запуска тестов для сообщества Ruby.
На наших рабочих серверах у нас есть до (до) N параллельных процессов, выполняющих N наборов тестов на N виртуальных машинах параллельно, т.е. один рабочий процесс запускает один набор тестов на одной виртуальной машине за раз, но N из них работают одновременно.
Теперь, когда многие рабочие процессы фактически выполняют сборки параллельно, производительность каждой сборки значительно ухудшится по сравнению с тем, когда одна и та же сборка будет запускаться в одном рабочем процессе (и ничто другое не работает параллельно).
Вот пример:
Эта «матрица сборки» состоит из 20 отдельных сборок:
http://staging.travis-ci.org/#!/svenfuchs/rails/builds/1906
В то время, когда это было запущено, было запущено 10 рабочих, поэтому эта сборка началась с 10 отдельных сборок, выполняемых в 10 рабочих (и виртуальных машинах) параллельно. Эта сборка - одна из них, и на ее выполнение ушло ~ 2 часа:
[см. последнюю ссылку в списке на странице выше, я могу разместить только 2 URL]
Сама же сборка займет всего ~ 20 минут, если другие сборки не выполняются параллельно. Вот пример этого:
http://staging.travis-ci.org/#!/svenfuchs/rails/builds/1927
Очевидно, что это снижение производительности - это то, что нам нужно решить, но мы не уверены, где искать.
Набор тестов в основном выполняет процессы Ruby, которые могут вызывать оболочку и порождать несколько других процессов Ruby, каждый из которых выполняет модульные тесты в базе кода. Некоторые из них попадают в базы данных, такие как MySQL, Sqlite3 и Postgres, но мы также замечаем такое же ухудшение с тестами, которые вообще не попадают ни в одну базу данных.
Рабочий сервер, на котором размещены эти процессы и виртуальные машины, выглядит так:
Каждая ВМ:
Будем очень признательны за любые подсказки о том, как разобраться в этом или, возможно, просто лучше определить основную проблему.
Спасибо!
Вы не упоминаете, каков базовый диск на этих серверах, но подобные проблемы с производительностью почти всегда связаны с вводом-выводом. Как выглядит статистика ввода-вывода, когда вы запускаете несколько сборок вместо одной?
Кроме того, вы получите гораздо лучшую производительность своего оборудования, используя что-то вроде Xen или VMware ESXi, а не VirtualBox.
Вы когда-нибудь пытались изменить следующее vm.attributes?
attribute :cpus
attribute :synthcpu
Однажды я столкнулся с проблемами во время интенсивного распараллеливания на виртуальной машине VirtualBox, которая на самом деле использовала больше потоков, чем может обслуживать хост и настроенная виртуальная машина. Тогда мне помогло сокращение количества виртуальных процессоров.
Это может быть подсказкой, где искать ..
Ссылки на атрибуты можно найти там:
config.vm.customize: http://vagrantup.com/docs/vagrantfile.html Атрибуты ВМ: http://mitchellh.github.com/virtualbox/VirtualBox/VM.html
Удачи.. :)
Я немного запутался на сервере. Сервер - это процессор с 12 процессорами x i7-950, четырехъядерный процессор? Какая коробка может это сделать? Если он существует, я хочу его! Вы также упоминаете гексакор, но часть 950 - это четырехъядерный процессор. Сколько реальных ядер у вас доступно? Поскольку я никогда не слышал о плате 12x для i7, я предполагаю, что вы имеете в виду, что у вас есть 2 i7-970 (которые являются hecacore), всего 12 ядер и 12 ГБ оперативной памяти.
Мне ваша проблема кажется довольно ясной. Вы используете OS + 10 виртуальных машин, и каждой виртуальной машине выделяется 4 ядра. Это 40 виртуальных ядер плюс еще 1, по крайней мере, для ОС в коробке с 12 физическими ядрами (24 с гиперпоточностью). Я ожидал, что 2 виртуальные машины будут хорошо работать с этой конфигурацией, а затем увидим серьезную деградацию за ее пределами.
Если у вас действительно есть то, что вы описываете (12 x i7-950), то есть 48 реальных ядер, и в этом случае проблема заключается в оперативном вводе-выводе.
У меня нет особого опыта работы с виртуальным боксом, но я знаю vmWare и оборудование.
Удачи
Я бы тоже заподозрил диск io. Однако вы не упомянули, какие проверки вы уже выполнили для этого. верхняя? вмстат? iostat?
Было бы интересно построить график нагрузки процессора на количество виртуальных боксов и посмотреть, не произойдет ли внезапное падение производительности. Может быть, с двумя или тремя вы действительно получите линейное увеличение производительности, но как только вы достигнете десяти, оно падает. Это также может быть вызвано памятью io, которая имеет те же проблемы, что и диск io, хотя и с большей скоростью: программное обеспечение может больше не помещаться в кеш, поэтому оно должно получать свои данные из памяти, что является общий для 12 других процессоров.
только мои 2 цента.