Мы работаем с двумя броузерами с двумя узлами, каждый из которых имеет совершенно разные очереди и рабочие нагрузки. Каждая коробка имеет 24 ядра (H/T) стоимостью Xeon E5645 @ 2,4 ГГц с 48 ГБ оперативной памяти, подключенную через Gigabit LAN с задержкой ~ 150 мкс, работает RHEL 5.6, RabbitMQ 3.1, Erlang R16B с отключенным HiPE. Мы пробовали работать с HiPE, но это не оказало заметного влияния на производительность и было очень катастрофическим.Факторы производительности зеркальной очереди
Похоже, что мы достигли высоты потолка для наших сообщений от 1000 до 1400/с как внутри, так и снаружи. Это брокерский, а не для очереди. Добавление большего количества потребителей не улучшает пропускную способность в целом, просто дает этой конкретной очереди больший кусок этого очевидного «пула» ресурса.
Каждая очередь зеркально отражается на двух узлах, составляющих брокера. Наши издатели и потребители в равной мере одинаково соединяются с обоими узлами. Мы также отмечаем ADSL-подобную асимметрию в ставках; если нам удастся опубликовать высокую скорость сообщений, скорость доставки снизится до двухзначных цифр. Тестирование с не зеркальной очередью имеет гораздо более высокую пропускную способность, как и ожидалось. Очереди и обмены долговечны, сообщения не являются постоянными.
Мы хотели бы знать, что мы можем сделать, чтобы улучшить ситуацию. ЦП на коробке отлично, луч занимает половину ядра для 1 процесса, затем еще 80% каждого из двух ядер для еще нескольких процессов. Остальная часть коробки, по сути, не работает. Мы используем ~ 20 ГБ оперативной памяти в пользовательском пространстве, а кеш системы заполняет остальные. IO ставки прекрасны. Сеть прекрасна.
Есть ли какие-либо настройки Erlang/OTP, которые мы можем сделать? delegate_count является значением по умолчанию 16, может кто-нибудь объяснить, что это делает немного более подробно, пожалуйста?