Почему мой сайт Tomcat / Alfresco перестает отвечать каждые полдня или около того? - PullRequest
0 голосов
/ 17 июня 2009

Я разработчик, работающий над веб-сайтом CentOS 5 с Apache Tomcat 6.x, Alfresco Labs 3 (автономный файл .war) и парой пользовательских веб-приложений.

Сервер работал без проблем последние несколько месяцев, но на днях кто-то загружал изображение через Alfresco, и сайт перестал отвечать. Кроме того, все веб-приложения, запущенные через Tomcat, также не отвечали. Я попытался подключиться по локальной сети (например, telnet localhost 80), но время ожидания истекло без подключения.

Просматривая самый последний файл журнала (localhost ... log), я увидел трассировку стека, начинающуюся с java.lang.OutOfMemoryError: сбой пространства PermGen и после некоторого поиска в Google увеличил максимальный размер perm со 128 МБ до 384 МБ. Мы думали, что это решит проблему, но сегодня она вернулась, и tomcat снова вышел из строя (за исключением того, что в журналах нет трассировки стека PermGen)

Другая трассировка стека, которая продолжает появляться, следующая:

Jun 16, 2009 3:38:26 PM org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet default threw exception
java.lang.IllegalStateException
    at org.apache.catalina.connector.ResponseFacade.sendError(ResponseFacade.java:407)
    at org.apache.struts2.dispatcher.Dispatcher.sendError(Dispatcher.java:707)
    at org.apache.struts2.dispatcher.Dispatcher.serviceAction(Dispatcher.java:485)
    at org.apache.struts2.dispatcher.FilterDispatcher.doFilter(FilterDispatcher.java:395)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
    at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845)
    at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
    at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
    at java.lang.Thread.run(Thread.java:619)

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

Кроме этого, я не совсем уверен, что делать. На самом деле я не знаю никаких других улик, чтобы проверить. Я предполагаю, что это проблема под открытым небом, но я не могу сказать точно. Единственное, что я сделал сегодня, чтобы изменить конфигурацию, это увеличил размер permgen до 512 МБ, но это может не помочь, так как на этот раз мы не получили ошибку PermGen.

Есть идеи?

Ответы [ 3 ]

1 голос
/ 17 июня 2009

Здесь от 256 до 512 МБ стабилизированного повторного восстановления нестабильности tomcat permgen здесь. Двойное ОЗУ гарантирует временное улучшение и, скорее всего, позволяет исправить ситуацию от исправлений к разработке. В противном случае вы теряете время на профилирование, узнаете почему, а потом все равно удваиваете ОЗУ.

1 голос
/ 19 июня 2009

Вы также должны искать утечку памяти - загружаете ли вы классы из войны, которые могут быть загружены из общей библиотеки? Кроме того - некоторые классы журналирования могут заставить tomcat удерживать загруженные классы (что и заполняет пространство permgen) от GC'd. Посмотрите на загрузчики классов tomcat и убедитесь, что вы загружаете не больше, чем нужно из загрузчиков классов уровня приложения.

1 голос
/ 17 июня 2009

самое простое исправление может заключаться в том, чтобы проверить, есть ли у версии tomcat, которую вы используете, эта ошибка в любых других версиях, возможно, вам просто нужно обновить / вернуть tomcat.

нашел это, надеюсь, это полезно

http://www.nabble.com/-jira--Created:-(WW-3106)-SEVERE:-Servlet.service()-for-servlet-default-threw-exception-java.lang.IllegalStateException-(Shows-a-BLANK-PAGE-to-user)-td23291783.html

...