Утечка памяти в нескольких приложениях

У меня есть утечка памяти в двух приложениях на сервере Tomcat 6.0.35, которая появилась "из ниоткуда". Одно приложение — Solr, а другое — наше собственное программное обеспечение. Я надеюсь, что кто-то видел это раньше, так как это происходило со мной в течение последних нескольких недель, и мне приходится постоянно перезапускать Tomcat в производственной среде.

Он появился на нашем исходном сервере, несмотря на тот факт, что ни один код, связанный с потоком или операцией соединения с БД, не был затронут. Поскольку старый сервер, на котором работает это приложение, должен был быть удален, я перенес сайт на новый сервер и в «более чистую» среду с идеей, которая удалит все устаревшие вещи. Но это продолжает происходить.

Непосредственно перед завершением работы Tomcat журнал catalina.out заполняется такими ошибками, как:

2012 -04 -25 21 :46 :00,300 [main] ОШИБКА org.apache.catalina.loader.WebappClassLoader -Веб-приложение [/AppName], похоже, запустило поток с именем [MultiThreadedHttpConnectionManager cleanup], но не смогло его остановить. Это очень вероятно, чтобы создать утечку памяти.

2012 -04 -25 21 :46 :00,339 [main] ОШИБКА org.apache.catalina.loader.WebappClassLoader -Веб-приложение [/AppName], похоже, запустило поток по имени [com.mchan ge.v2.async.ThreadPoolAsynchronousRunner$PoolThread -#2], но не смог его остановить. Это очень вероятно, чтобы создать утечку памяти.

2012 -04 -25 21 :46 :00,470 [main] ОШИБКА org.apache.catalina.loader.WebappClassLoader -Веб-приложение [/AppName] все еще обрабатывает запрос, который еще не закончил иш. Это очень вероятно, чтобы создать утечку памяти.Вы можете контролировать время, отведенное для завершения запросов, с помощью атрибута unloadDelay стандартного Conte. хт реализация.

Во время этой миграции мы перешли с Solr 1.4 -> Solr 3.6 в попытке решить проблему. Когда вышеприведенные ошибки начинают заполнять журнал, ошибка Solr ниже следует сразу после повторения 10 -15 раз, а затем tomcat перестает работать, и мне приходится выключать и запускать, чтобы заставить его реагировать.

2012 -04 -25 21 :46 :00,527 [main] ОШИБКА org.apache.catalina.loader.WebappClassLoader -Веб-приложение [/solr] создало ThreadLocal с ключом тип [орг.а pache.solr.schema.DateField.ThreadLocalDateFormat] (значение [org.apache.solr.schema.DateField$ThreadLocalDateFormat@1f1e90ac] )и значение типа [org.apache.solr. schema.DateField.ISO8601CanonicalDateFormat] (значение [org.apache.solr.schema.DateField$ISO8601CanonicalDateFormat@6b2ed43a] ), но не удалось удалить его, когда веб-сайт приложение было остановлено. Это очень вероятно, чтобы создать утечку памяти.

Мое исследование выявило много предложений по изменению кода, который управляет потоками, чтобы убедиться, что они уничтожают соединения в пуле БД и т. д., но этот код не менялся почти 12 месяцев. Кроме того, приложение Solr дает сбой, и это сторонняя сторона, поэтому я думаю, что это конфликт окружающей среды (jar, управление версиями, конфигурация с жирными пальцами?)

Мое последнее изменение заключалось в обновлении коннектора mysql для java до последней версии, поскольку в более ранних выпусках существовали некоторые ошибки с утечкой памяти, связанные с объединением в пул, но всего через несколько часов сервер снова вышел из строя.

Одна вещь, которую я только что заметил, это то, что я вижу тысячи сеансов в веб-менеджере Tomcat, но это может быть отвлекающим маневром.

Если кто-то видел это, мы очень признательны за любую помощь.

[Изменить]

Кажется, я нашел источник проблемы. В конце концов, это была не утечка памяти.Я взял приложение от другой группы разработчиков, которое использует c3p0 для объединения баз данных через Hibernate. c3p0 имеет ошибку/особенность, из-за которой, если вы не освобождаете соединения с БД, c3p0 может перейти в состояние ожидания после того, как все соединения (через MaxPoolSize :по умолчанию равны 15 ). Он будет бесконечно ждать, пока соединение станет доступным. Отсюда и мой ларь.

Я увеличил MaxPoolSize сначала с 25 ->100, и мое приложение работало несколько дней без зависаний, а затем со 100 ->1000, и с тех пор (более 2 недель оно стабильно работает ).

Это не полное решение, так как мне нужно выяснить, почему у него заканчиваются соединения из пула, поэтому я также установил для параметра unreturnedConnectionTimeout c3p0 значение 4 часа, что применяет 4-часовое ограничение времени для всех соединений, независимо от того, активны они или нет. Если это активное соединение, оно закроет его и снова -откроет.

Некрасиво, и c3p0 не рекомендует это, но это дает мне некоторую передышку, чтобы выяснить источник проблемы.

Примечание. :при использовании c3p0 с Hibernate настройки сохраняются в вашем файле persistence.xml, но не все настройки можно поместить туда. Некоторые настройки (, например. unreturnedConnectionTimeout )должен идти в c3p0.properties