Вопрос по linux, java, jvm – Что может привести к значительному превышению Java-процессом Xmx или Xss-лимита?

13

У меня есть 7 разных java-демонов, которые я запускаю (все 7) на 3 разных серверах. В командной строке Java есть -Xmx2048m и -Xss1024k. На этих 3 серверах все 21 процесса показывают чуть менее 2,5 ГБ для размера VIRT сверху и снизу. Размер RES варьируется от 300 до 1,9 ГБ в зависимости от того, какой это демон.

Все так и должно быть.

Введите новый сервер. Более быстрый процессор, больше оперативной памяти (16 ГБ вместо 8 ГБ), немного более новая версия Java (1.6.0_10-b33 на старых серверах, 1.6.0_31-b04 на новом сервере). Обе системы (и JVM) являются 64-битными.

Переместил 2 демонов на новый сервер. На новом сервере, выполняющем ту же задачу, демоны потребляют значительно больше ЦП (примерно на уровне ядра) и выполняют меньше задач. (Переведено с 5110 процессоров на старых системах на 5620-е на новой).

Достаточно много дополнительного ядра процессора (поток GC ??) и отчет 5 ГБ VIRT и 2 ГБ RES для одного демона и 10,5 ГБ VIRT и 2 ГБ RES для другого демона.

Есть идеи, что заставило бы Java игнорировать (или, кажется, игнорировать, если это так) ограничения памяти?

VIRT - это виртуальная память, которая не имеет прямого отношения к пространству кучи. Я рекомендую прочитать ответы на этот вопрос: Stackoverflow.com / вопросы / 4893192 / Процесс-памяти против-кучи[email protected] J Matt Ball
Xmx не определяет использование памяти JVM; он определяет максимальный размер пула выделения кучи, который является лишь одним из пулов памяти, используемых JVM. skaffman
GC1, больше пермского пространства. (Угадайка, но подходит для версий.) Вы можете попытаться заставить виртуальные машины использовать другой gc. esej
@ MattBall Интересное чтение. Я не слежу за памятью из-за памяти, приложение работает плохо под нагрузкой и в 4 раза потребляет печать VIRT, выполняющую точно такую же задачу (тот же набор данных). Так как любая память, которая появляется в VIRT, была malloc'd и поэтому может фактически использоваться в любой момент, и ее указатели являютсявероятн (но не обязательно), пройденный потоком GC, кажется, что это может указывать, если не быть виновным, на то, что вызывает ужасную производительность. Wayne Walker
Вы пробовали использовать ту же версию Java на новой машине? Они оба одинаковы? Dave Newton

Ваш Ответ

1   ответ
11

Короткий ответ для меня был:

export MALLOC_ARENA_MAX = 1

Это уменьшило нагрузку на процесс (VIRT сверху) в 5 раз. Вернемся к уровням CentOS 5.

В последних версиях glibc появилась новая функция «пулы памяти для каждого потока»:

http: //www.centos.org/docs/5/html/5.4/Technical_Notes/glibc.htm

Последний элемент в разделе журнала 1.71.1 обсуждает его (и ссылается на непубличную ошибку ....)

Возможно, вы захотите установить для MALLOC_ARENA_MAX значение 4 вместо 1, чтобы получить некоторые преимущества многопоточной памяти, на которые было рассчитано изменение. Смотрите это: questions.apache.org/jira/browse/HADOOP-715 michael

Похожие вопросы