Что является хорошим инструментом для исследования использования подключения к базе данных в Java?

Что такое хороший инструмент для исследования использования подключения к базе данных в Java?

Разработчик поддерживает сложную Java-программу, которая, по сути, исчерпывает количество доступных подключений к базе данных. Поскольку проблема является спорадической, было бы полезно узнать, какой поток открыл несколько соединений с базой данных, чтобы сфокусировать усилия в этой области.

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

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

Ответ 1

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

Я предполагаю, что вы используете последовательный метод на стороне java, чтобы получить соединение db (объединенное или нет, не имеет значения).

Идея заключается в создании очень легкого класса оболочки вокруг вашего соединения factory/pool или любого другого. Обертка реализует любой интерфейс jdbc, поэтому вы можете поменять его для обычного объекта соединения, но большинство методов просто прозрачно вызовет/вернет базовое соединение.

Если вы используете какую-то структуру IoC (например, spring), вы должны иметь возможность легко менять класс соединения /factory на уровне конфигурации. Теперь все ваши java-коды будут использовать вашу новую оболочку db-подключения.

Если вы используете пул, то вызов connection.close() обычно просто возвращает объект в пул вместо того, чтобы уничтожить соединение. Таким образом, этот метод работает для нормальной утечки соединения или просто "не возвращается в пул (исчерпанный пул)".

Теперь нам просто нужно записать интересные биты и установить ловушку для просочившихся соединений.

Трассировка стека для идентификации создателя

В конструкторе или методе factory для вашей оболочки соединения создайте новый объект Throwable и сохраните его как локальную переменную в вашей обертке позже. Мы используем Throwable, потому что это быстрее/дешевле, чем при использовании Thread.currentThread().getStackTrace().

Установите "ловушку"

Внедрите метод finally в свой класс-оболочку. Это метод очистки, вызываемый GC, когда объект уничтожается, потому что он больше не используется.

Метод finally должен проверить "я закрыт?". Если он уже закрыт, тогда все в порядке... однако, если соединение GCed и оно не закрыто... то это "утечка" соединения.

Теперь Throwable возвращается в игру. Мы можем захватить Throwable и вывести сообщение с хорошим сообщением, в котором говорилось что-то вроде: "Я просочился в соединение, и вот трассировка стека, подразумевающая моего создателя".

Расширение идеи

Этот метод может быть адаптирован для различных ситуаций. Разумеется, вы можете хранить другие типы данных в своей обертке для устранения неполадок вашей конкретной проблемы. Например, время создания. Затем вы можете опросить для долгоживущих соединений и снова вовлечь создателя. Или вы можете опросить существующие соединения и проанализировать трассировки стека Throwable, чтобы получить данные о том, какой код использует количество подключений с течением времени.

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

Ответ 2

Посмотрите log4jdbc. Это позволяет вам просматривать все, что происходит через ваш jdbc, включая соединения открытия/закрытия, а также информацию о номере соединения.

Ответ 3

Кто-то недавно показал мне ConnLeakFinder, "простой инструмент для точного определения утечек соединения jdbc в Java-коде". Я до сих пор не тестировал его сам, но он должен позволять вам видеть, кто не закрыл соединение после использования. См. Connection + Leak + How + To + Find.htm.

Но на самом деле вам следует использовать пул соединений (например c3p0).

Ответ 5

P6Spy - это среда с открытым исходным кодом для поддержки приложений, которые перехватывают и, возможно, изменяют утверждения базы данных.

От http://www.p6spy.com/about.html
В дистрибутив P6Spy входят следующие модули:

  • P6Log. P6Log перехватывает и регистрирует операторы базы данных любого приложения, использующего JDBC. Это приложение особенно полезно для разработчиков для отслеживания операторов SQL, создаваемых серверами EJB, что позволяет разработчику писать код, который обеспечивает максимальную эффективность на сервере. P6Spy предназначен для установки через несколько минут и не требует изменений кода.
  • P6Outage. P6Outage обнаруживает долговременные операторы, которые могут указывать на провал сбоев базы данных и записывать любое утверждение, которое превосходит настраиваемый временной интервал во время его выполнения. P6Outage был разработан, чтобы свести к минимуму любое нарушение производительности регистрации, регистрируя только длинные операторы.