Я изучаю возможность запуска приложения Java на компьютере с очень большим объемом оперативной памяти (от 300 ГБ до 15 ТБ, возможно, на машине SGI Altix 4700), и мне любопытно, как Java GC вероятно, будет выполняться в этом сценарии.
Я слышал, что JVM IBM или JRockit могут быть лучше подходят для этого, чем Sun. Кто-нибудь знает какие-либо исследования или данные о производительности JVM в этой ситуации?
В Sun JVM вы можете использовать опцию -XX: UseConcMarkSweepGC, чтобы включить маркер Concurrent и Sweep Collector, что позволит полностью исключить фазы "остановить мир" алгоритма GC по умолчанию, за счет немного больше накладных расходов.
Советуем использовать больше, чем на ВМ на такой машине, ИМХО устарела. В реальных приложениях часто есть достаточно общих данных, чтобы производительность с CMS и одной JVM была лучше.
Вопрос: хотите ли вы работать в рамках одного процесса (JVM) или нет? Если да, то у вас будет проблема. См. Настройка виртуальных машин Java, Руководство пользователя Oracle Coherence и аналогичная документация. Эмпирическое правило, которым я управлял, - это попытка избежать куч размером более 1 ГБ. В то время как полные GC на 512 МБ-1 ГБ могут занимать менее секунды. Полноценный GC 2-4 ГБ может занять 5 секунд или дольше. Obvioiusly это зависит от многих факторов, но мораль этой истории заключается в том, что накладные расходы GC не масштабируются линейно, и как только вы попадаете в один ряд производительности диапазона, то быстро разлагается.
Sun JVM позволяет вам настраивать и оптимизировать извлечение мусора, но это наука для себя: http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html
Возможно, вам придется немного почитать и исследовать, но для такого типа компьютеров параметры GC, оптимизированные для машины и приложения, вероятно, имеют большое значение.
Начиная с 5.0, Hotspot JVM использует концепцию, известную как Эргономика, чтобы попытаться оптимизировать использование памяти. Это основано не только на простом объеме доступной памяти, но и на размерах кучи эффектов, размерах генерации и алгоритмах сбора мусора.
Начните с чтения этого, что объясняет эргономику и многое другое:
http://java.sun.com/j2se/reference/whitepapers/memorymanagement_whitepaper.pdf
Там также парень по имени Брайан Гетц, который написал многочисленные статьи о том, как Java выделяет и использует память, и все это можно найти здесь:
Это совсем не ответит на ваш вопрос, но если вы планируете развернуть огромное приложение Java, вам может быть интересно изучить устройства Azul Systems. Говорят, что они могут собирать мусор, не создавая паузу в приложении до одной кучи 670 ГБ.
Возможно, вы захотите запустить на этом компьютере виртуальный кластер Terracotta.
В предыдущих ответах на вопрос есть несколько дополнительных ответов
Единственные люди, которые действительно могут сказать вам, это SGI. Суперкомпьютеры не ведут себя как обычные серверы только больше.
Однако я обнаружил, что Java лучше всего работает, когда память является локальной для процессоров, обращающихся к ней. Примечание: GC должен иметь возможность перемещать всю память до конца. Это означает, что он плохо масштабируется, если у вас есть дизайн, похожий на много компьютеров, склеенных вместе, что может быть здесь. Размер модуля памяти составляет 32 ГБ, поэтому вы можете получить более высокую производительность, если вы ограничите свой JVM комфортно вписывающимся в этот размер.
Принятый ответ для этого поста довольно старый и теперь устарел. По состоянию на сентябрь 2014 года, если вы используете Java 7, вам, вероятно, следует переключиться на сборщик GC1. Из примечаний к выпуску версии 7 7:
http://www.oracle.com/technetwork/java/javase/7u4-relnotes-1575007.html
"Коллекционер G1 предназначен для приложений, которые полностью используют большой объем памяти, доступный на современных многопроцессорных серверах, сохраняя при этом задержку сбора мусора. Приложения, требующие большой кучи, имеют большой активный набор данных, или неравномерные рабочие нагрузки или страдают от длительных временных сбоев, связанных с сборкой мусора, должны выиграть от перехода на G1".
Разумеется, ответ о том, как GC собирается выполнять, "кто заботится?"; -)