Каково Максимальное пространство кучи Java для SuSE Linux

Question

Этот вопрос связан с Java отказывается запускаться - Не удалось освободить достаточно места для кучи объектов и должно быть достаточно легко разобраться.Однако;мои поиски не дали ничего полезного.

По сути, у нас есть 2 32-разрядные ОС (RedHat и SuSE) на разных машинах с одинаковым оборудованием.Оба используют одну и ту же JVM, оба выполняют одну и ту же командную строку.RedHat работает отлично, но SuSE сообщает, что памяти недостаточно.

Нам просто нужно знать, является ли это ограничением используемой нами версии SuSE или это что-то другое.

'cat /proc/version' дает нам:

Linux version 2.6.5-7.244-bigsmp (geeko@buildhost) (gcc version 3.3.3 (SuSE Linux)) #1 SMP Mon Dec 12 18:32:25 UTC 2005

'uname -a' дает нам следующее на ОБОИХ типах машин:

UTC 2005 i686 i686 i386 GNU/Linux

Answer 1

Лимит памяти JVM связан с наибольшим свободным смежный доступный блок, а не объем свободной памяти.Лимит варьируется примерно от 1,4 ГБ до чуть более 2,0 ГБ и зависит от того, куда ваша операционная система помещает различные элементы в памяти.Я не знаю подробностей о том, где Redhat или Suse загружают данные в память, но может быть, что suse сопоставляет какую-то библиотеку с адресом в середине оперативной памяти, где Redhat может сопоставить ее в конце (предположение).

И помните, что ваше фактическое использование памяти в java составляет более чем то, что вы указываете для Xmx.Другие настройки памяти также влияют на размер вашей кучи (например, permgen).Таким образом, также может быть, что пространство перманентности в Suse имеет большее значение по умолчанию, чем в Redhat.

Кроме того, в зависимости от профиля выделения памяти вашего приложения вам может сойти с рук меньший размер кучи и другие варианты сбора мусора.Здесь есть некоторые подробности (http://java.sun.com/performance/reference/whitepapers/tuning.html) и в других местах.Например, если вы выделяете много небольших временных блоков, вам понадобятся другие настройки GC, чем если бы у вас было много битовых долгоживущих объектов.

Что касается связанного вопроса, почему бы просто не использовать Redhat?Это может быть упрощенным решением, но я гарантирую, что оно решит вашу проблему быстрее, чем глубокое погружение в таинственный мир настройки Java и управления памятью ОС : P

Answer 2

Во-первых, вы сумасшедший, что используете 32-разрядную ОС, когда у вас так много адресного пространства.Перейдите на 64-разрядную JVM в 64-разрядном Linux.Сколько времени вы уже потратили впустую, пытаясь диагностировать эту проблему, которая, как вы, должно быть, подозревали с самого начала, исчезнет с увеличением адресного пространства 64-разрядной системы ?

Во-вторых, хорошо известно, что из всех поставщиков Linux в штате Red Hat больше всего инженеров по ядру, и она вносит серьезные изменения в ядра своих продуктов RHEL.Они часто включают исправления для больших рабочих нагрузок, подобных вашей (ну, это большая рабочая нагрузка для 32-разрядной системы, в 64-разрядной нет ничего особенного).Так что есть некоторый шанс, что причина в конечном счете в том, что у RHEL есть другие клиенты, делающие те же безумные вещи, что и вы, и вы получаете выгоду от работы, которую они проделали, чтобы поддержать этих клиентов.

Наконец, поскольку я подозреваю, что вы будете настаивать на попытке найти способ сделать это на 32-разрядной SuSE, я укажу, что Linux предлагает множество компромиссов в адресном пространстве на 32-разрядной x86, и возможно (но не наверняка), что в ваших системах SuSE просто выбран другой компромисс.Если вы можете вызвать конфигурацию запущенных ядер (часто в /boot/ config ....), то вы можете сравнить настройки, такие как HIGHMEM.

Обычным вариантом еще несколько лет назад было разделение 2: 2, то есть пользовательское пространство ограничено 2 гигабайтами адресного пространства, что является простым решением для программирования и обладает приличной эффективностью, но в этом сценарии, очевидно, вы не сможете получить запрошенную кучу, поскольку это не оставило бы места для текста программы, стека и т.д.Совсем недавно появилась тенденция к соотношению 3: 1 (аналогично переключению Windows / 3GB), которое расширяет адресное пространство пользовательского пространства за счет втискивания самого ядра ОС в меньшее пространство, что потенциально вызывает свои собственные проблемы.Это могло бы сработать, но там было бы очень тесно, так что я также не удивился бы, если бы это не сработало для вашей работы.Наконец, более новые ядра Linux также предлагают опцию, при которой вы получаете 32-разрядное пользовательское пространство размером 4 ГБ, чего может быть достаточно для обеспечения надежной работы ваших заданий при значительных затратах производительности, поскольку тогда очевидно, что адреса пользовательского пространства и ядра не могут сосуществовать.

Чтобы попробовать это, вам понадобится новое ядро.Возможно, вы сможете просто установить один из них, предоставленный SuSE (посмотрите, предлагают ли они другие на выбор, напримеропция "PAE") или вам, возможно, придется скомпилировать свой собственный, и в этом случае это, вероятно, аннулирует ваш контракт на поддержку.

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