Tomcat на производственном сервере, PermGen и передислокации

Похоже на

 MemoryError: PermGen space
 java.lang.OutOfMemoryError: PermGen space

- общая проблема. Вы можете увеличить размер вашего пространства перм, но после повторного развертывания 100 или 200 он будет заполнен. Отслеживание утечек памяти ClassLoader почти невозможно.

Каковы ваши методы для Tomcat (или другого простого контейнера сервлетов - Jetty?) на рабочем сервере? Перезагружается ли сервер после каждого развертывания решения?

Используете ли вы один Tomcat для многих приложений?

Может быть, я должен использовать многие серверы Jetty на разных портах (или встроенный Jetty) и каждый раз отказываться от развертывания/перезапуска/развертывания?

Ответ 1

Я отказался от использования диспетчера tomcat и теперь всегда отключил tomcat для повторного развертывания.

Мы запускаем два кота на одном сервере и используем веб-сервер apache с mod_proxy_ajp, чтобы пользователи могли получать доступ к обоим приложениям через один и тот же порт 80. Это хорошо также потому, что пользователи видят страницу Apache Service Unavailable, когда tomcat не работает.

Ответ 2

Вы можете попробовать добавить эти варианты Java:

-XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled

Это позволяет сборку мусора в пространстве PermGen (по умолчанию отключена) и позволяет GC разгружать классы. Кроме того, вы должны использовать -XX: PermSize = 64m -XX: MaxPermSize = 128m, упомянутый в других местах, чтобы увеличить доступность PermGen.

Ответ 3

Да, это проблема. Мы используем три веб-приложения на сервере Tomcat: № 1 использует инфраструктуру веб-приложений, Hibernate и многие другие JAR, нет. 2 использует Hibernate и несколько JAR и нет. 3 - в основном очень простое JSP-приложение.

Когда мы развертываем no. 1, мы всегда перезапускаем Tomcat. В противном случае космическая ошибка PermGen скоро укусит нас. № 2 иногда могут быть развернуты без проблем, но поскольку это часто меняется, когда нет. 1 тоже, перезапуск запланирован в любом случае. № 3 не представляет никаких проблем и может быть развернут так часто, как это необходимо без проблем.

Итак, да, мы обычно перезапускаем Tomcat. Но мы также с нетерпением ждем Tomcat 7, который должен обрабатывать многие проблемы загрузчика памяти/класса, которые зацикливаются на разных сторонних JAR и фреймворках.

Ответ 4

Переключатели PermGen в HotSpot только задерживают проблему, и в итоге вы все равно получите OutOfMemoryError.

У нас была эта проблема долгое время, и единственным решением, которое я нашел до сих пор, является использование JRockit. У него нет PermGen, поэтому проблема просто исчезает. Сейчас мы оцениваем его на наших тестовых серверах, и у нас не было проблемы с PermGen с момента переключения. Я также попытался перераспределить более 20 раз на своей локальной машине с приложением, которое получает эту ошибку при первом повторном развертывании, и все красиво красиво.

JRockit предназначен для интеграции в OpenJDK, поэтому, возможно, эта проблема уйдет и на запас Java в будущем.

http://www.oracle.com/technetwork/middleware/jrockit/overview/index.html

И это бесплатно, по той же лицензии, что и HotSpot:

https://blogs.oracle.com/henrik/entry/jrockit_is_now_free_and

Ответ 5

Вам следует включить сборку мусора PermGen. По умолчанию Hotspot VM НЕ собирает мусор PermGen, что означает, что все загруженные файлы классов остаются в памяти навсегда. Каждое новое развертывание загружает новый набор файлов классов, что означает, что вы в конечном итоге исчерпали пространство PermGen.

Ответ 6

Какую версию Tomcat вы используете? У Tomcat 7 и 6.0.30 есть много возможностей избежать этих утечек или, по крайней мере, предупредить вас об их причинах.

Эта презентация от Марка Тома из SpringSource (и давнего комминера Tomcat) по этому вопросу очень интересна.

Ответ 7

С другой стороны, есть новая версия инструмента Plumbr, который также может отслеживать и обнаруживать утечки постоянного поколения.