Недостаточно свободного места с тонким драйвером tomcat 6 dbcp и oracle 11 - PullRequest
1 голос
/ 24 марта 2011

Я запускаю веб-приложение на Tomcat 6, используя Tomcat DBCP для управления соединениями JDBC. Это приложение может работать с MySQL, SQL Server, и мы недавно начали тестирование на Oracle. В отличие от MySQL и SQL Server, когда мы начали использовать тонкий драйвер Oracle, наше приложение начало использовать бесконечную память.

Приложение работает на сервере Windows 2008 и устанавливает Oracle 11g. Tomcat работает как сервис, с максимальной памятью в 2 гигабайта, -XX: MaxPermSize = 1024m и максимальный размер стека потока 1024k. Настройки DBCP имеют максимальный активный уровень 20 и максимальный уровень холостого хода 10. Оставленный для запуска на некоторое время, он займет все 2 гигабайта и начнет отчет:

java.lang.OutOfMemoryError: пространство кучи Java

Наше использование JDBC довольно элементарно. Мы получаем соединение из источника данных JDBC, выполняем наши запросы или обновления и вызываем close () для результата, оператора и соединения (если каждый существует).

При работе с драйвером MySQL 5 или драйвером JTDS мы можем использовать менее 1 гигабайта памяти. Разница лишь в драйвере Oracle.

Что я могу сделать, чтобы остановить это?

Обновление (30 марта 2011 г.): Я добавил комментарии в качестве ответов ниже. Кто-нибудь может помочь?

Вот ответы на комментарии:

База данных не находится на том же сервере, что и Tomcat. Сервер, на котором размещен Tomcat, имеет 8 гигабайт физической памяти.

Я не закрываю соединение после каждого использования. Я использую DBCP Tomcat, и я вызываю close () после каждого использования, но для пула установлено максимальное активное значение 20, максимальное время простоя 10.

Версия тонкого драйвера, которую я использую, - 11.2.0.2.0.

Что касается -Xmx, я запускаю его как службу, с «Начальным пулом памяти» 1024 МБ, «Максимальным пулом памяти» 2048 МБ и «Размером стека потоков» 1024 КБ

У меня нет трассировки стека - ошибки нет до тех пор, пока не закончится ошибка памяти (без трассировки стека).

Ответы [ 2 ]

0 голосов
/ 04 мая 2013

Ответ Винета хороший.Вот отличная ссылка, объясняющая стратегию кэширования драйверов 11g и почему этот ответ имеет смысл: http://www.oracle.com/technetwork/database/enterprise-edition/memory.pdf.

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

0 голосов
/ 04 июня 2011

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

Всякий раз, когда OOME (OutOfMemoryError) встречается во время работы приложения, использующего JDBC, получение дампа кучи более или менее помогает в устранении основной причины проблемы. В некоторых случаях OOME выбрасывается естественным образом, без какой-либо утечки. Это связано с тем, что сама куча истощается. Такая ситуация может возникнуть, когда в результате выполнения оператора JDBC возвращается большой набор результатов.

Объекты, созданные драйвером JDBC Oracle при создании набора результатов, по-видимому, довольно тяжелые, даже если они недолговечны (для большинства приложений не сохраняются ссылки на набор результатов после получения требуемых данных). Возвращение большого количества элементов данных (большое количество строк или столбцов) обязательно приведет к этому сценарию.

В этом случае для разрешения доступны только следующие варианты:

  • Увеличение объема памяти, доступной для кучи Java.
  • Перепишите запрос, если возможно, чтобы получить меньший набор данных.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...