Опыт перехода на 64-битную JVM - PullRequest
5 голосов
/ 31 марта 2010

Наша компания планирует перейти на 64-битную JVM, чтобы обойти ограничение максимального размера кучи в 2 ГБ. Google дал мне очень смешанные результаты о производительности 64-битной JVM. Кто-нибудь пробовал перейти на 64-битную Java и поделиться своим опытом

Ответы [ 5 ]

9 голосов
/ 01 апреля 2010

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

Более длинные ответы / комментарии:

  • Комментарий о том, что Java является 32-битной дизайн вводит в заблуждение. Джава адресация памяти либо 32, либо 64-битная, но спецификация VM гарантирует, что большинство полей (например, int, long, double, и т. д.) одинаковы независимо.

  • Также - GC настраивает комментарии, пока уместно по количеству объектов, май не имеет значения, GC может быть быстрым JVM с большими кучами (я работал с кучами до 15Гб, с очень быстрый GC) - это зависит больше от того, как ты играешь с поколением коллектор схемы, а какой твой Шаблон использования объекта. Хотя в Прошлые люди потратили много энергии параметры настройки, это очень рабочая нагрузка зависимые и современные (Java 5+) JVM очень хороши в самонастройке - если только у вас есть много данных, вы больше может навредить себе, чем помочь с агрессивной настройкой JVM.

  • Как уже упоминалось в архитектурах x86, 64-битные процессоры EMT64 или x64 также включить новые инструкции для делать такие вещи, как атомарные записи, или другие варианты, которые также могут повлиять высокопроизводительные приложения.

3 голосов
/ 31 марта 2010

отлично работает для нас. Почему бы вам просто не попробовать настроить его и запустить набор нагрузочных тестов под профилировщиком, таким как jvisualvm?

3 голосов
/ 31 марта 2010

Если вам нужна большая куча, то вопросы производительности довольно спорны, не так ли? Или у вас есть план горизонтального масштабирования?

Основная проблема, с которой я столкнулся в 64-битных приложениях, заключается в том, что полная сборка мусора может занять очень много времени (поскольку она основана на количестве живых объектов). Итак, вы хотите тщательно настроить параметры GC, чтобы избежать полных сборов (я слышал один анекдот о компании, у которой было 64 Гб кучи, и настроил свой GC так, чтобы они никогда не перешли на полный GC; они просто закрыли вниз один раз в неделю).

Кроме этого, следует признать, что Java является 32-битной по своему дизайну, поэтому вряд ли вы увидите значительное увеличение производительности при перемещении данных по 64 бита за раз. И вы все еще ограничены 32-битными индексами массивов.

1 голос
/ 15 апреля 2010

Наивно принимая 32-битные рабочие нагрузки JVM и переводя их на 64-битные, я получаю снижение производительности и пространства.

Однако большинство крупных поставщиков JVM в настоящее время внедрили хорошую технологию, которая, по сути, сжимает часть кучи - это называется сжатые ссылки или сжатые операции для 64-битных JVM, которые не являются «большими» (т.е. Диапазон 30 ГБ).

Это имеет большое значение и должно сделать переход 32-> 64 гораздо более слабым.

Ссылка на IBM JVM: текст ссылки

1 голос
/ 31 марта 2010

Мы написали напрямую в 64-битную систему, и я не вижу никаких неблагоприятных действий ...

...