Производительность Java с очень большим объемом оперативной памяти

Question

Я изучаю возможность запуска приложения Java на компьютере с очень большим объемом оперативной памяти (где-то от 300 ГБ до 15 ТБ, возможно, на компьютере SGI Altix 4700), и мне любопытно, как GC Java скорее всего, в этом сценарии.

Я слышал, что виртуальные машины IBM или JRockit могут лучше подходить для этого, чем Sun. Кто-нибудь знает какие-либо исследования или данные о производительности JVM в этой ситуации?

Answer 1

В Sun JVM вы можете использовать опцию -XX: UseConcMarkSweepGC, чтобы включить одновременную метку и очистку Collector, что позволит практически полностью избежать этапов "остановить мир" алгоритма GC по умолчанию, за счет немного больше накладных расходов.

ИМХО советует использовать больше, чем на ВМ на такой машине, устарело. В реальных приложениях у вас часто достаточно общих данных, чтобы производительность с CMS и одной JVM была выше.

Answer 2

Вопрос в том, хотите ли вы запустить в рамках одного процесса (JVM) или нет? Если вы это сделаете, то у вас будут проблемы. См. Настройка виртуальных машин Java , Руководство пользователя Oracle Coherence и аналогичная документация. Эмпирическое правило, которым я руководствуюсь - старайся избегать кучи размером более 1 ГБ. Принимая во внимание, что полный GC 512MB-1GB может занять меньше секунды. Полный GC на 2-4 ГБ потенциально может занять 5 секунд или дольше. Очевидно, что это зависит от многих факторов, но мораль этой истории заключается в том, что накладные расходы GC не масштабируются линейно, и как только вы попадаете в диапазон производительности в одну секунду, он быстро ухудшается.

Answer 3

Начиная с 5.0, Hotspot JVM использует концепцию, известную как эргономика, для оптимизации использования памяти. Это основано не только на объеме доступной памяти и влияет на размеры кучи, размеры генерации и алгоритмы сборки мусора.

Начните с прочтения этого, которое объясняет эргономику и многое другое:

http://java.sun.com/j2se/reference/whitepapers/memorymanagement_whitepaper.pdf

Есть также парень по имени Брайан Гетц, который написал множество статей о том, как Java выделяет и использует память, все из которых и многое другое можно найти здесь:

http://www.briangoetz.com/pubs.html

Answer 4

JVM от Sun позволяет вам настраивать и оптимизировать сбор мусора, но это сама по себе наука: http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html

Возможно, вам придется немного почитать и исследовать, но для такого типа машины настройки ГХ, оптимизированные для машины и приложения, вероятно, имеют большое значение.

Answer 5

Это совсем не ответ на ваш вопрос, но если вы планируете развернуть огромное Java-приложение, вам может быть интересно изучить устройства Azul Systems . Говорят, что можно собирать мусор без паузы в приложении до одной кучи 670 ГБ.

Answer 6

Возможно, вы захотите запустить виртуальный Terracotta кластер на этой машине.

Answer 7

Принятый ответ на этот пост довольно старый и устарел. По состоянию на сентябрь 2014 года, если вы используете Java 7, вам, вероятно, следует переключиться на сборщик GC1. Из примечаний к выпуску обновления 4 для Java 7:

http://www.oracle.com/technetwork/java/javase/7u4-relnotes-1575007.html

"Сборщик G1 предназначен для приложений, которые в полной мере используют большой объем памяти, доступный на современных многопроцессорных серверах, и в то же время сохраняют контроль задержек при сборке мусора. Приложения, которые требуют большой кучи, имеют большой активный набор данных, имеют пакетный или неравномерная рабочая нагрузка, или длительные задержки, вызванные сборкой мусора, должны выиграть от перехода на G1. "

Answer 8

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

Однако я обнаружил, что Java работает лучше всего, когда память локальна для процессоров, обращающихся к ней. Примечание: GC должен иметь возможность обходить всю память от начала до конца. Это означает, что он плохо масштабируется, если у вас есть дизайн, похожий на множество компьютеров, соединенных вместе, что может быть в данном случае. Размер модуля памяти составляет 32 ГБ, поэтому вы можете получить более высокую производительность, если ограничите JVM, чтобы он подходил под этот размер.

Answer 9

В предыдущих ответах на похожий вопрос

есть несколько дополнительных ответов.

Answer 10

Конечно, ответ на вопрос о том, как собирается GC: «кого это волнует?» ; -)