Как NUMA-архитектура влияет на производительность ActivePivot?

Question

Мы переносим приложение ActivePivot на новый сервер (4 сокета Intel Xeon, 512 ГБ памяти). После развертывания мы запустили наш тест приложений (это сочетание больших запросов OLAP одновременно с транзакциями реального времени). Измеренная производительность почти в два раза медленнее, чем на предыдущем сервере, у которого есть аналогичные процессоры, но в два раза меньше ядер и в два раза меньше памяти.

Мы исследовали различия между двумя серверами, и он кажется, что большая имеет архитектуру NUMA (неравномерная память). Каждый процессорный сокет физически близок к 1/4 памяти, но дальше от остальной части ... JVM, который запускает наше приложение, выделяет большую глобальную кучу, на каждом узле NUMA есть случайная доля этой кучи. Наш анализ состоит в том, что шаблон доступа к памяти довольно случайный, а ядра ЦП часто теряют время, обращаясь к удаленной памяти.

Мы следим за дополнительной информацией об использовании ActivePivot на NUMA-переключателях. Можем ли мы сконфигурировать кубы ActivePivot или пулы потоков, изменить наши запросы, настроить операционную систему?

Answer 1

Питер описал общие варианты JVM, доступные сегодня, чтобы снизить влияние NUMA-характеристик на производительность. Чтобы это было коротко, JVM, поддерживающий NUMA, будет разбивать кучу по отношению к узлам NUMA, а когда поток создает новый объект, объект выделяется в узле NUMA ядра, который запускает этот поток (если тот же поток позже использует он, объект будет в локальной памяти). Также при уплотнении кучи NUMA JVM избегает перемещения больших блоков данных между узлами (и уменьшает длину событий stop-the-world).

Так что на любом аппарате NUMA и для любого приложения Java опция -XX: + UseNUMA должна быть включена.

Но для ActivePivot это не помогает: ActivePivot - это база данных в памяти. Существуют обновления в режиме реального времени, но основная часть данных хранится в основной памяти в течение всего срока службы приложения. Независимо от параметров JVM данные будут разделены между узлами NUMA, а потоки, выполняющие запросы, будут случайным образом получать доступ к памяти. Зная, что большинство разделов механизма запросов ActivePivot работают так же быстро, как память, могут быть извлечены, влияние NUMA особенно заметно.

Итак, как вы можете максимально использовать решение ActivePivot на оборудовании NUMA?

Существует простое решение, когда приложение ActivePivot использует только часть ресурсов (мы обнаруживаем, что часто бывает, что несколько решений ActivePivot работают на одном сервере). Например, решение ActivePivot, использующее только 16 ядер из 64 и 256 ГБ из TeraByte. В этом случае вы можете ограничить сам процесс JVM узлом NUMA.

В Linux вы предварить запуск JVM с помощью следующей опции (http://linux.die.net/man/8/numactl):

numactl --cpunodebind=xxx 

Если весь сервер посвящен одному решению ActivePivot, вы можете использовать в ActivePivot распределенной архитектуры для разделения данных. Если есть 4 узла NUMA, вы запускаете 4 JVM, на которых размещаются 4 узла ActivePivot, каждый из которых связан с узлом NUMA. С помощью этого развертывания запросы распределяются между узлами, и каждый узел будет выполнять свою долю работы при максимальной производительности в пределах нужного узла NUMA.

Answer 2

Вы можете попробовать использовать -XX:+UseNUMA

http://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html

Если это не даст результата вы ожидаете, вы, возможно, придется использовать taskset для блокировки JVM для конкретного сокета и эффективно разбить сервер на четыре машины с одним JVM каждый.

Я заметил, что машина с большим количеством сокетов имеет более медленный доступ к их памяти (даже их локальную память) и как всегда дает вам выигрыш в производительности, который вы хотите получить.