Определение размера кучи JVM в гостях VMware - PullRequest
Новая
       23

Определение размера кучи JVM в гостях VMware

6 голосов
/ 13 января 2009

Этот вопрос, вероятно, лучше сформулирован: как работа сервера Java на гипервизоре, таком как VMware ESX, влияет на кучу Java?

  • Доступ к куче JVM является случайным с точки зрения ОС / гипервизора
  • Гостевой ОС или гипервизору трудно оптимизировать память, доступ к которой осуществляется случайным образом
  • Учитывая это, может ли гипервизор обнаруживать неиспользуемые страницы в куче JVM?

Общепринятое мнение о серверных приложениях Java заключается в том, что производительность лучше всего, если вы выделяете всю кучу при запуске JVM, а не позволяете динамически изменять размер кучи по мере необходимости. Другими словами, если вы установите размер кучи равным 1 ГБ, ваш Java-процесс получит 1 ГБ непрерывного виртуального адресного пространства (+ все, что нужно для двоичных файлов), память, которая больше не доступна другим приложениям.

Достаточно ли умен VMware, чтобы обнаружить, что часть этой кучи фактически не используется? Как это влияет на производительность ГХ? Было бы лучше позволить динамически изменять размер кучи в VMware? Какие стратегии GC лучше всего работают с гостями VMware?

Кроме того, кто-нибудь подскажет мне рекомендации по настройке куч JVM в виртуализированных средах?

Ответы [ 2 ]

5 голосов
/ 14 января 2009

Относится к моему вопросу:

Вот PDF-файл, в котором представлен широкий обзор вопросов, связанных с запуском Java на гостях VMware: текст ссылки

2 голосов
/ 23 ноября 2010

, поэтому в этом случае убедитесь, что Reservation = OS vRAM + JVM + размер кучи надеюсь, это поможет.

, но в то же время ниже приведены общие рекомендации с сайта VMware KB:

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

Установите значение резервирования памяти в клиенте инфраструктуры VMware равным объему памяти для виртуальной машины. Поскольку любой тип перестановки памяти (физический или виртуальный) отрицательно влияет на производительность кучи JVM, особенно для сборки мусора.

Определите оптимальное количество виртуальных процессоров для виртуальной машины, на которой размещено приложение Java, путем тестирования виртуальной машины, настроенной на различное количество виртуальных процессоров, в разное время с одинаковой нагрузкой.

Если вы используете несколько потоков сборщика мусора в своей JVM, сопоставьте количество этих потоков с количеством виртуальных процессоров, которые настроены на виртуальной машине.

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

Если ваш сервер ESX перегружен, убедитесь, что Balloon Driver работает на виртуальной машине, чтобы память оптимально управлялась.

...