JVM Sun может обработать гигантские размеры "кучи" без проблем, и как?

Очевидно, что размер кучи не неограничен, и чем больше размер кучи, тем больше ваша JVM в конечном итоге потратит на сборщик мусора. Хотя я думаю, что на 64-битной JVM можно установить довольно большой размер кучи, я все же считаю, что это не совсем практично. Совет здесь: лучше иметь несколько JVM, работающих с одинаковыми параметрами, то есть кластер узлов JBoss / Tomcat, работающих на одной физической машине, и вы получите лучшую пропускную способность.

РЕДАКТИРОВАТЬ : Также ваше поведение GC зависит от таксономии вашей кучи. Если у вас много недолговечных объектов, и каждый запрос к серверу создает их много, тогда ваш GC будет очень часто собирать много мусора, и, следовательно, при большом размере кучи это приведет к более длительным паузам. Если у вас очень много долгоживущих объектов (например,

Как уже писал Крис Райс, я бы не ожидал каких-либо очевидных проблем с GC для размеров кучи до 32-64 ГБ, хотя, конечно, может быть какой-то момент в логике вашего приложения, который может вызвать проблемы.

Не имеет прямого отношения к GC, но я все же рекомендую вам выполнить реалистичный нагрузочный тест в вашей производственной системе. Раньше я работал над проектом, где у нас была аналогичная установка (относительно большая кластерная установка JBoss / Tomcat для обслуживания общедоступного веб-приложения), и без преувеличения JBoss не очень хорошо себя ведет при высокой нагрузке или большом количестве одновременных вызывает, если вы используете EJB. JBoss тратит много времени на синхронизированные блоки при доступе к пулам экземпляров EJB и управлении ими, и если вы выберете кластер, он даже будет ждать внутрикластерной сетевой связи в этих синхронизированных блоках. Обратите особое внимание на низкую репликацию состояния, если вы используете SFSB.

# 1. В следующем случае, как бы вы настроили параметры кучи и GC?

Во-первых, наличие 64 гигабайт памяти не означает, что вы должны использовать их все для одной JVM. На самом деле это скорее означает, что вы можете запускать многие из них. Тогда невозможно ответить на ваш вопрос без какого-либо доступа к вашей машине и приложению для измерения и анализа вещей (недостаточно знать, что делает ваше приложение). И нет я m не запрашивает доступ к вашей среде :)

# 2. Будут ли заметны прерывания (паузы JVM и т. Д.), Которые будут замечены конечными пользователями?

Цель настройки - найти хороший компромисс между частотой и продолжительностью (основных) GC. С кучей ~ 55 г сборщик мусора будет выполняться не часто, но наверняка займет заметное время (чем больше куча, тем дольше основной сборщик мусора). Использование параллельного или параллельного сборщика мусора поможет в многопроцессорных системах, но не решит полностью эту проблему. Зачем вам ~ 55g (это мега-огромное количество для веб-приложения IMO), вот мой вопрос. Я бы предпочел запустить много кластерных JVM для обработки нагрузки, если это необходимо (в какой-то момент база данных все равно станет узким местом для приложения, ориентированного на данные).

№3. Должно ли это действительно работать? Думаю, должно.

Хм ... не уверен, что понял вопрос. Что такое « это »? Создание JVM с большой кучей? Да, должно. Это эквивалентно запуску нескольких JVM? Нет, конечно, нет.

PS: 4G - это максимальный теоретический предел кучи для 32-разрядной JVM, работающей в 64-разрядной операционной системе (см. Почему я не могу получить большую кучу с 32-разрядной JVM? )

PPS: На 64-битных виртуальных машинах у вас есть 64-битная адресуемость для работы, что приводит к максимальному размеру кучи Java, ограниченному только объемом физической памяти и пространством подкачки, предоставляемым вашей системой. (см. Насколько большую кучу я могу создать с помощью 64-разрядной виртуальной машины? )

4G - это максимальный теоретический предел кучи для 32-разрядной JVM, работающей в 64-разрядной операционной системе (см. Почему я не могу получить кучу большего размера с 32-разрядной JVM? )

PPS : На 64-битных виртуальных машинах у вас есть 64-битная адресуемость для работы, в результате чего максимальный размер кучи Java ограничен только объемом физической памяти и пространством подкачки, предоставляемым вашей системой. (см. Насколько большую кучу я могу создать с помощью 64-разрядной виртуальной машины? )

4G - это максимальный теоретический предел кучи для 32-разрядной JVM, работающей в 64-разрядной операционной системе (см. Почему я не могу получить кучу большего размера с 32-разрядной JVM? )

PPS : На 64-битных виртуальных машинах у вас есть 64-битная адресуемость для работы, в результате чего максимальный размер кучи Java ограничен только объемом физической памяти и пространством подкачки, предоставляемым вашей системой. (см. Насколько большую кучу я могу создать с помощью 64-разрядной виртуальной машины? )

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

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

Если у вас есть приложение, которое не помещается в один банк памяти, ваше приложение должно использовать память, которая не является локальной для процессора и использовать память, локальную для другого процессора.

В Linux вы можете запустить numactl --hardware, чтобы увидеть структуру процессоров и банков памяти.

Только чтобы добавить еще несколько переключателей, которые я бы использовал по умолчанию: -Xms55g может помочь сократить время разгона, потому что он освобождает Java от необходимости проверять, может ли он вернуться к исходному размеру и позволяет также улучшить внутренний начальный размер областей памяти.

Кроме того, мы сделали хороший опыт с NewSize, чтобы дать вам большой молодой размер, чтобы избавиться от краткосрочного мусора: -XX: NewSize = 1g Кроме того, большинство веб-приложений создают много короткого времени мусор, который никогда не переживет обработку запроса. Вы даже можете сделать это больше. С Xms55g виртуальная машина уже резервирует большой кусок. Возможно, уменьшение размера может помочь.

-Xincgc помогает постепенно очищать молодое поколение и часто возвращать процессор в потоки пользователя.

-XX: CMSInitiatingOccupancyFraction = 70 Если вы действительно заполняете всю эту память, попробуйте запустить сборку мусора CMS ранее.

-XX: + CMSIncrementalMode переводит CMS в инкрементный режим, чтобы чаще возвращать процессор в потоки пользователя.

Присоединитесь к процессу с помощью jstat -gc -h 10 1s и наблюдайте за работой GC.

Неужели вы заполните память? Я предполагаю, что 64 процессора для обработки запросов могут даже работать с меньшим объемом памяти. Что у вас там хранится?