Потребление памяти Java, "top" и HP-Ux

Question

Мы поставляем Java-приложения, которые работают на Linux, AIX и HP-Ux (PA-RISC). Похоже, мы изо всех сил пытаемся получить приемлемый уровень производительности в HP-Ux от приложений, которые прекрасно работают в двух других средах. Это относится как к времени выполнения, так и к потреблению памяти.

Хотя мне еще предстоит найти определенную статью о «почему», я считаю, что измерение потребления памяти с помощью «top» является грубым подходом из-за таких вещей, как общий код, дающий вводящие в заблуждение результаты. Тем не менее, это все, что нам нужно сделать на сайте заказчика, где потребление памяти в HP-Ux стало проблемой. Это стало проблемой только в этот раз, когда мы перешли с Java 1.4 на Java 1.5 (на HP-Ux 11.23 PA-RISC). Под «проблемой» я подразумеваю, что машина перестала создавать новые процессы, потому что мы исчерпали все 16 ГБ физической памяти.

Измеряя «до» и «после» общей «свободной памяти», мы пытаемся измерить, сколько было использовано Java-приложением. Я написал быстрое приложение, которое хранит 10 000 случайных 64-битных строк в ArrayList, и попробовал этот подход для измерения потребления в Linux и HP-Ux в Java 1.4 и Java 1.5.

Результаты:

HP Java 1,4 ~ 60 МБ

HP Java 1,5 ~ 150 МБ

Linux Java 1.4 ~ 24MB

Linux Java 1.5 ~ 16MB

Может кто-нибудь объяснить, почему могут возникнуть эти результаты? Это какая-то особенность способа, которым «верх» измеряет свободную память? Действительно ли Java 1.5 на HP потребляет в 2,5 раза больше памяти, чем Java 1.4?

Спасибо.

Answer 1

JVM могут просто иметь разные параметры по умолчанию. Куча будет расти до размера, который вы настроили, чтобы позволить ей. По умолчанию на виртуальной машине Sun установлен определенный процент ОЗУ в машине - то есть, по умолчанию Java будет использовать больше памяти, если вы используете машину с большим объемом памяти.

Я был бы очень удивлен, если бы на виртуальной машине HP-UX не было много настроек для такого рода вещей HP. Я бы посоветовал вам поэкспериментировать с обоими параметрами - выяснить, какой наименьший максимальный размер кучи вы можете использовать без ущерба для производительности или пропускной способности.

Answer 2

У меня нет коробки HP для проверки моей гипотезы. Однако на вашем месте я бы использовал профилировщик, такой как JConsole (поставляется с JDK) ИЛИ yourkit, чтобы измерить происходящее.

Однако, похоже, вы начали измерения после того, как увидели что-то неладное; Так что я НЕ скрываю, что это происходит - просто указываю вам на то, что я сделал бы в такой же ситуации.

Answer 3

Возможно, вам также захочется взглянуть на проблему, которую вы пытаетесь решить ... Я не представляю, что есть много проблем, которые потребляют 16 ГБ памяти и не требуют хорошего раунда оптимизации.

Вы запускаете несколько виртуальных машин? Вы читаете большие наборы данных в память и не удаляете их достаточно быстро? и т. д. и т. д.

Answer 4

Во-первых, неясно, что вы измерили тестом "10000 случайных 64-битных строк". Вы должны запустить приложение, измерить его загрузочную область памяти и запустить тест. Вполне возможно, что Java 1.5 получает больше кучи сразу после запуска (например, из-за настроек менеджера кучи).

Во-вторых, мы запускаем приложения Java под 1.4, 1.5 и 1.6 под HP-UX, и они не предъявляют особых требований к памяти. У нас есть аппаратное обеспечение Itanium.

В-третьих, почему вы используете топ? Почему бы просто не напечатать Runtime.getRuntime (). TotalMemory ()?

В-четвертых, добавляя значения в ArrayList, вы создаете фрагментацию памяти. ArrayList должен удваивать свое внутреннее хранилище время от времени. В зависимости от настроек GC и реализации ArrayList.ensureCapacity () объем не собранной памяти может существенно различаться между 1,4 и 1,5.

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