Комментарии 39
Вот тебе бабушка и garbage collector.
Наличие GC не освобождает от обязанности задействовать мозг при написании кода.
Приведите пример программного кода в Java для принудительной очистки памяти?
System.gc();?
Методы System.gc() и Runtime.gc() выглядят, как «запустить сборщик мусора», но и на них нельзя полагаться, поскольку другие более приоритетные потоки могут отложить их выполнение. И на самом деле, документация для методов gc() гласит: «Вызов этих методов подразумевает, что JVM приложит усилия для переработки неиспользуемых объектов».
Приведите пример программного кода в Java для принудительной очистки памяти?Нет такого кода, да и речь не о том. Даже с GC от программиста сильно зависит насколько рационально будет использоваться память и как часто будет вызываться GC.
НЛО прилетело и опубликовало эту надпись здесь
Интересно пишете.
на машинах с 32-битной архитектурой. Особенно на windows, где по умолчанию, память на один процесс ограничена двумя гигабайтами.Почему «особенно»? А где по другому?
На UNIX больше можно. Сколько точно не знаю, но там только один хип (-Xmx) можно выдавать до 3G.
в винде с флагом /3GB тоже 3 будет
Ну так больше 4G процесс не может адресовать физически, какой бы чудесной система ни была) А сколько в чистом отдать процессу за вычетом системы — это уже от ОС только зависит. И в винде можно отдать 3+ гб и в линуксах.
Бтв, где-то читал, что на «родной» solaris под джаву можно выделить практически полные 4Гб (типа 3.9 там было)
Дело в том, что JVM требует непрерывный кусок виртуальной памяти, а винда по легаси причинам мапит в вирт память в районе отметки 3Гб всякий хлам: куски ядра, видео память и т.п. Поэтому память для JVM можно выделить только от конца ядра и до 3Гб. Именно поэтому под виндой трудно создать джава машину с хипом более 1.2-1.4Гб.
Я тогда абзац про флаг в windows из своей статьи удаляю? pyatigil, можете дать ссылку про то что вы говорите? Или есть еще эксперты в этой области подтвердить сказанное pyatigil?
Вот пруф, на сановском блоге: blogs.sun.com/moazam/entry/why_can_t_i_allocate
Размер задается параметрами -Xms и -Xmx.
Возможно, -Xmn на рисунке — это опечатка, и должно значиться -Xms?
Вопрос к автору: а в пункте 4 вы не рассматривали вариант с пулом потоков? Или он вам не подошёл?
Ну у меня вебсервер был. Тогда еще Servlet API 3.0 не было. Так что пул добавить для асинхронной обработки каких-то действий пользователя я не мог.
Хотя на самом деле томкат-то использует внути пул, чтобы обрабатывать запросы клиентов. Просто если он маленький, а клиентов много, то они начинают отваливаться по HTTP с таймаутом, поэтому размер этого пула и пришлось увеличивать все больше и больше.
Хотя на самом деле томкат-то использует внути пул, чтобы обрабатывать запросы клиентов. Просто если он маленький, а клиентов много, то они начинают отваливаться по HTTP с таймаутом, поэтому размер этого пула и пришлось увеличивать все больше и больше.
У нас на build-сервере tomcat 6.0.30, ежедневно он валится с PermGen Space.
Мы считаем, что это от постоянных редеплоев аппликух. Доктор, это лечится? :)
Мы считаем, что это от постоянных редеплоев аппликух. Доктор, это лечится? :)
Я же давал ссылку в на свой блок в этой статье в пункте про PermGen, где подробно описывается почему это может происходить и что с этим делать.
Конечно каждый конкретный случай надо разбирать отдельно. Если же не хочется разбираться, профайлить и искать причину, чтобы её фиксить, то если у вас CMS, попробуйте
Или еще вариант — возьмите JRocket (попробовать можно бесплатно), там говорят вообще проблем нет.
Или дождитесь пока oracle JRocket смержит в HotSpot.
Конечно каждый конкретный случай надо разбирать отдельно. Если же не хочется разбираться, профайлить и искать причину, чтобы её фиксить, то если у вас CMS, попробуйте
-XX:+CMSPermGenSweepingEnabled
-XX:+CMSClassUnloadingEnabled Или еще вариант — возьмите JRocket (попробовать можно бесплатно), там говорят вообще проблем нет.
Или дождитесь пока oracle JRocket смержит в HotSpot.
JRockit, а так плюс
CMSPermGenSweepingEnabled устаревший параметр. Достаточно -XX:+CMSClassUnloadingEnabled
Неправда, что в JRockit нет этой проблемы. Просто она проявляется позже. Если Hotspot ограничивает размер class metadata, то JRockit позволяет забивать невыгружаемыми классами всю доступную виртуальную память. Однако если утечка памяти есть, она в любом случае проявится рано или поздно, причем в случае исчерпания виртуальной памяти последствия могут крайне неприятными: тормоза, уход в своп, блокировка работы других процессов на машине.
В принципе, уже можно потихоньку начинать радоваться избавлению Hotspot'а от PermGen. Уже сейчас вынесены из PermGen в C-heap symbols, interned strings и static fields. Впрочем, спорное решение, на мой взгляд.
Неправда, что в JRockit нет этой проблемы. Просто она проявляется позже. Если Hotspot ограничивает размер class metadata, то JRockit позволяет забивать невыгружаемыми классами всю доступную виртуальную память. Однако если утечка памяти есть, она в любом случае проявится рано или поздно, причем в случае исчерпания виртуальной памяти последствия могут крайне неприятными: тормоза, уход в своп, блокировка работы других процессов на машине.
В принципе, уже можно потихоньку начинать радоваться избавлению Hotspot'а от PermGen. Уже сейчас вынесены из PermGen в C-heap symbols, interned strings и static fields. Впрочем, спорное решение, на мой взгляд.
> CMSPermGenSweepingEnabled устаревший параметр. Достаточно -XX:+CMSClassUnloadingEnabled
Правильно, надо или нет добавлять CMSPermGenSweepingEnabled зависит от версии Java. Тем кто еще сидит на пятерке вполне может понадобиться.
В JRockit я не силен. Просто об этом сказали на javaone. За что купил, за то и продаю.
Правильно, надо или нет добавлять CMSPermGenSweepingEnabled зависит от версии Java. Тем кто еще сидит на пятерке вполне может понадобиться.
В JRockit я не силен. Просто об этом сказали на javaone. За что купил, за то и продаю.
Возможно у вас проблемы с log4j на томкате. Погуглите log4j tomcat permgen. В ранних версиях томката класслоудер не освобождал классы log4j при андеплое, что приводило к увеличению их, когда приложуха несколько раз передеплоивалась
Да, вот статья по теме: blogs.sun.com/fkieviet/entry/classloader_leaks_the_dreaded_java
И еще одна, про решение проблемы: www.samaxes.com/2007/10/classloader-leaks-and-permgen-space/
если есть настроение — нужно просто посмотреть, что туда лоадится, а потом не анлоадится. Попробуйте ключи -XX:+TraceClassLoading -XX:+TraceClassUnloading. Другой кандидат — intern строк.
НЛО прилетело и опубликовало эту надпись здесь
это не все варианты — есть еще нехватка direct buffers, которая по своему выглядит и проявляется
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Какие бывают типы OutOfMemoryError или из каких частей состоит память java процесса