Вопросы Теги

макс. размер "кучи" Java, сколько слишком много

От чего Вы добираетесь ulimit -n? Это должно дать Вам Ваше "Максимальное количество открытых дескрипторов файлов", для каждого процесса.

Править: Вы видите, сколько дескрипторов файлов процесс использует путем следования инструкциям здесь и здесь.

Пределы ресурса могут быть установлены для пользователей во время входа в систему путем редактирования /etc/security/limits.conf. Посмотрите man limits.conf и man pam_limits для деталей.

1
задан 9 March 2010 в 22:15
4 ответа

В то время как я не запустил приложений JRuby на Tomcat, я запустил приложения ColdFusion на варьировавшихся серверах приложений J2EE, и у меня также были подобные проблемы.

В этих часто задаваемых вопросах Вы будете видеть, что SOracle говорит, что в 32-разрядном Windows, Вы будете ограничены макс. размером "кучи" 1,4 к 1,6 ГБ. Я никогда не смог получить его стабильный, что высоко, и я подозреваю, что Вы выполняете подобную конфигурацию.

Мое предположение - то, что Ваши запросы занимают много времени для выполнения b/c с размером "кучи", что высоко, JVM выделила больше физической памяти, чем Windows должен был дать, и таким образом Windows проводит много времени, загружая страницы и из памяти к диску, таким образом, это может обеспечить необходимый объем памяти к JVM.

Моя рекомендация, хотя парадоксальный, состояла бы в том, что Вы на самом деле понижаете макс. размер "кучи" где-нибудь к приблизительно 1,2 ГБ. Можно повысить минимальный размер также, если Вы замечаете, что существует замедление в обработке запросов приложения, в то время как JVM должна попросить, чтобы Windows больше памяти увеличил размер своей "кучи", поскольку это заполняется неинкассированными объектами.

1
ответ дан 3 December 2019 в 16:58
  • 1
    i' m вполне уверенный you' право ре. Хотя we' ре, запускающее Linux (не окна), I' m вполне уверенный, что машина подкачивает слишком много и нелегко собирать "мусор". –  brad 10 March 2010 в 17:24

Часть Вашей проблемы - то, что Вы, вероятно, исчерпали ресурсы все другие процессы для поршня. Мое общее эмпирическое правило для -Xms и -Xmx следующие:

-Xms : <System_Memory>*.5
-Xmx : <System_Memeory>*.75

Таким образом на системы на 4 ГБ это было бы: -Xms2048m -Xmx3072m, и в Вашем случае я пошел бы с -Xms896m -Xmx1344

2
ответ дан 3 December 2019 в 16:58

в addiotion к предыдущим ответам необходимо также принять PermGen во внимание. PermGen не является частью пространства "кучи". с Вашей текущей конфигурацией Ваш процесс Java мог суммировать до 1792 МБ, который является общей суммой Вашей машины.

2
ответ дан 3 December 2019 в 16:58
  • 1
    ya я просто читал об этом также, we' ре, определенно исчерпавшее ресурсы система с комбинацией перманента и макс. "кучей" –  brad 10 March 2010 в 17:23
  • 2
    О, да - that' s положительная сторона также. У Вас есть ссылка для PermGen, не являющегося частью пространства "кучи"? –  Clint Miller 10 March 2010 в 18:01
  • 3
    это сообщение на stackoverflow объясняет модель памяти и также ahs ссылка на блог солнца с объяснением PermGen: stackoverflow.com/questions/2129044/… Вы также видите его в журнале gc (при включении): 0.431: [Full GC [PSYoungGen: 352K->0K(101952K)] [PSOldGen: 0K->330K(932096K)] 352K->330K(1034048K) [PSPermGen: 3959K->3959K(16384K)], 0.0187660 secs] Вы видите, что PermGen обрабатывается отдельно. –  Christian 11 March 2010 в 09:04

Я знаю, что уже существует выбранный ответ, но тем не менее, здесь идет мое объяснение.

В первую очередь, в командной строке Вы используете, Вы уже резервируете 1 536 мегабайтов для "кучи" Java (-Xmx1536m) и 256 мегабайтов для PermGen (-XX:MaxPermSize=256m). PermGen выделяется отдельно от "кучи" Java и используется для хранения классов Java, загруженных в JVM.

Эти 2 области вместе уже составляют в целом 1 792 мегабайта RAM.

Но в дополнение к этому, существует также RAM, должен был загрузить саму JVM (собственный код JVM) и RAM для хранения кода, который сгенерирован JIT-компилятором.

Я подозреваю все, что они составляют в целом 2 гигабайта, виртуальные, который Вы упомянули.

Наконец, также необходимо принять во внимание другие вещи, которые работают на сервере и той RAM потребности также. Вы действительно не упоминали, сколько подкачки используется на сервере. Это сказало бы Вам, подкачивает ли машина, и это заставляет приложение медленно реагировать. Необходимо в любом случае препятствовать тому, чтобы JVM поразила подкачку. Намного намного лучше часто инициировать сборщик "мусора", чем выделить слишком много "кучи" и иметь часть выгружаемой "кучи" Java.

1
ответ дан 3 December 2019 в 16:58

Теги

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