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

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

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

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

Ответ 1

Питер описал общие варианты JVM, доступные сегодня, чтобы снизить влияние NUMA-характеристик на производительность. Чтобы это было коротко, JVM, поддерживающий NUMA, будет разбивать кучу по отношению к узлам NUMA, а когда поток создает новый объект, объект выделяется в NUMA node ядра, который запускает этот поток (если тот же поток позже использует его, объект будет находиться в локальной памяти). Кроме того, при уплотнении кучи 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 node.

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

numactl --cpunodebind=xxx

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

Ответ 2

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

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

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

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