Опыт перемещения в JVM на 64 бита
Наша компания планирует переместиться в JVM на 64 бита для ухода от максимального предела размера "кучи" на 2 ГБ. Google дал мне очень смешанные результаты приблизительно 64 бита производительность JVM. Имеет любого, пытался переместиться в Java на 64 бита, и обменяйтесь своим опытом
5 ответов
Если вам нужна куча большего размера, тогда вопросы производительности довольно спорные, не так ли? Или у вас есть план горизонтального масштабирования?
Основная проблема, которую я слышал о 64-битных приложениях, заключается в том, что полная сборка мусора может занять очень много времени (поскольку она зависит от количества живых объектов). Итак, вы хотите тщательно настроить параметры сборщика мусора, чтобы избежать полных коллекций (я слышал один анекдот о компании, у которой было 64 ГБ кучи, и которая настроила свой сборщик мусора так, чтобы у них никогда не было полного сборщика мусора; они просто закрыли вниз раз в неделю).
В остальном следует учитывать, что Java является 32-битной по своей конструкции, поэтому вы вряд ли увидите какое-либо значительное увеличение производительности от перемещения данных на 64 бита за раз. И вы по-прежнему ограничены 32-битными индексами массива.
Мы написали прямо на 64-битную версию, и я не вижу неблагоприятного поведения ...
В двух словах: 64-битные JVM будут потреблять больше памяти для ссылок на объекты и некоторых других типов (обычно не существенно), потреблять больше памяти на поток (часто существенно на сайтах с большой нагрузкой) и позволят вам иметь большие кучи (обычно важно только если у вас много долгоживущих объектов)
Более длинные ответы/комментарии:
Комментарий о том, что Java является 32-битной по дизайну вводит в заблуждение. Java адресация памяти либо 32, либо 64-битной, но спецификация VM гарантирует, что большинство полей (например, int, long, double, и т.д.) одинаковы независимо от этого.
Также - комментарии по настройке GC, хотя и относящиеся к количеству объектов, могут быть не актуальны, GC может быть быстрым на JVM с большими кучами (я работал с кучами до 15 ГБ, с очень быстрым GC) - это больше зависит от того, как вы играете с генерационными схемами коллекторов, и какова ваша модель использования объектов. Хотя в прошлом люди тратили много энергии на настройку параметров, это очень зависит от рабочей нагрузки зависит от рабочей нагрузки, а современные JVM (Java 5+) очень хороши в самонастройке - если только если у вас нет большого количества данных, вы скорее скорее навредите себе, чем поможете агрессивной настройкой JVM.
Как уже упоминалось, на архитектурах x86, 64-битные процессоры EMT64 или x64 также включают новые инструкции для выполнения таких вещей, как атомарная запись, или другие возможности, которые также могут повлиять на высокопроизводительные приложения.
У нас все работает нормально. Почему бы вам просто не попробовать настроить его и запустить набор нагрузочных тестов под профайлером типа jvisualvm?
.Простое использование 32-битных рабочих нагрузок JVM и их перевод на 64-битные, по моему опыту, приводит к снижению производительности и экономии места.
Однако большинство основных поставщиков JVM в настоящее время внедрили хорошую технологию, которая по существу сжимает часть кучи - это называется сжатыми ссылками или сжатыми ошибками для 64-битных JVM, которые не являются «большими» (например, в 4- Диапазон 30 ГБ).
Это имеет большое значение и должно значительно снизить влияние перехода 32-> 64.
Ссылка на IBM JVM: текст ссылки