Преимущества / недостатки использования 64-разрядной JVM на 64-разрядном сервере Linux?

Question

Мы запускаем 32-битную Sun Java 5 JVM на 64-битных серверах Linux 2.6, но, очевидно, это ограничивает нашу максимальную память на процесс до 2 ГБ. Поэтому было предложено обновить 64-битную JVM, чтобы снять ограничение. В настоящее время мы запускаем несколько JVM (экземпляров Tomcat) на сервере, чтобы не превышать 2 ГБ, но мы хотели бы объединить их для упрощения развертывания.

Если вы сделали это, не могли бы вы поделиться своим опытом, пожалуйста? Вы работаете с 64-битной JVM? Вы бы порекомендовали остановиться на Java 5 или было бы нормально перейти на Java 6 и 64 бит одновременно? Стоит ли ожидать проблем с производительностью, лучше или хуже? Есть ли какие-то конкретные области, на которых мы должны сосредоточить наше регрессионное тестирование?

Спасибо за любые советы!

Answer 1

В Научном центре операций Kepler у нас около 50 машин с 32-64G каждая. Кучи JVM, как правило, 7-20G. Мы используем Java 6. ОС имеет ядро ​​Linux 2.6.

Когда мы перешли на 64-битную версию, я ожидал, что возникнут некоторые проблемы с запуском 64-битной JVM, но в действительности этого не было. Условия нехватки памяти труднее отлаживать, так как дампы кучи намного больше. Java Service Wrapper потребовались некоторые модификации для поддержки больших размеров кучи.

В Интернете есть несколько сайтов, утверждающих, что GC плохо масштабируется после 2G, но я не видел никаких проблем. Наконец, мы делаем интенсивные, а не интерактивные вычисления. Я никогда не смотрел на разницу в задержке; я предполагаю, что задержка GC в худшем случае будет больше при больших размерах кучи.

Answer 2

Мы используем 64-битную JVM с кучей около 40 Гб. В нашем приложении кешируется много данных, что приводит к большому «старому» поколению. Настройки сборки мусора по умолчанию не работали должным образом и требовали некоторой болезненной настройки на производстве. Урок: убедитесь, что у вас есть соответствующая инфраструктура нагрузочного тестирования, прежде чем вы начнете масштабироваться таким образом. Тем не менее, как только мы проработали изломы, производительность GC была отличной.

Answer 3

Я могу подтвердить опыт Шона. Мы работаем на чистых Java, ресурсоемких веб-сервисах (домашняя интеграция Jetty, с более чем 1 000 потоков сервлетов и более 6 ГБ загруженных данных в памяти), и все наши приложения очень хорошо масштабируются до 64-битной JVM, когда мы мигрировал 2 года назад. Я бы посоветовал использовать последнюю версию Sun JVM, так как в последних нескольких выпусках было сделано существенное улучшение в издержках GC. У меня не было никаких проблем с Wrapper от Tanukisoftware.

Answer 4

Любой код JNI, который вы написали и предполагает, что он работает в 32-битном формате, необходимо будет повторно протестировать Для проблем вы можете столкнуться с портированием кода c от 32 до 64 бит, смотрите эту ссылку. Это не специфично для JNI, но все еще применяется. http://www.ibm.com/developerworks/library/l-port64.html

Answer 5

После миграции на JDK6 64 бит с JDK5 32 бит (сервер Windows) мы обнаружили утечку в блоке памяти «perm gen space» После игры с параметрами JDK это было решено. Надеюсь, вам повезет больше, чем нам.

Answer 6

Если вы используете numactl --show, вы можете увидеть размер банков памяти на вашем сервере. Я обнаружил, что GC плохо масштабируется, когда он использует более одного банка памяти. Это скорее аппаратная проблема, чем программная проблема, ИМХО, но она все равно может повлиять на время GC.