Как обнаружить утечки соединения SqlServer в приложениях ASP.net?

Question

В настоящее время я тестирую GUI в приложении ASP.net 2.0. RDBMS - это SQL Server 2005. Хост - это Win Server 2003/IIS 6.0.

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

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

Я думаю, сборщик мусора .Net в конечном итоге закроет их, но ... это может занять некоторое время, нет?

У меня есть SQL Server Management Studio, и я вижу из монитора активности, что в базе данных открыто несколько соединений.

Из всего, что было сказано выше, вот некоторые вопросы, связанные с основным вопросом:

1. Есть ли способ узнать, в SQL Server 2005, если соединения открыты, потому что они ждут be , используемый в пуле соединений или если они открыты, потому что они используются приложением ?

2. знает Сомон хороших онлайн/бумажных ресурсов, где я мог бы узнать, как использовать производительности счетчики или какой-либо другой вид инструментов , чтобы помочь отследить такого рода вопросов?

3. Если счетчики производительности являются наилучшим решением , каковы переменные, которые I следует смотреть?

Answer 1

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

Кроме того, если вы используете IIS 6, вы можете настроить веб-приложение на использование отдельного пула приложений и установить другой вариант для утилизации памяти и процессов.

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

Если у вас есть доступ к SQL Server, вы можете контролировать соединения, выполненные из ваше приложение (есть счетчики производительности, определенные для каждого установленного экземпляра SQL Server).

Были некоторые статьи в MSDN Magazine. Также вы можете использовать библиотеку отладки SOS для присоединения к процессу приложения и проверить его вручную.

И, если у вас нет исходного кода, попробуйте использовать Reflector, чтобы получить источники приложения (они были бы очень полезно для отладки)

@Later редактировать: Вы могли бы проверить question здесь на stackoverflow.com слишком

Answer 2

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

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

Если открытые соединения были проблемой, на мониторе активности вы увидите ОЧЕНЬ большое количество соединений без активности.

Для счетчиков производительности вы можете начать просмотр объекта производительности «SQL Server: общая статистика».

Answer 3

Ссылка MSDN о (ADO.NET performance counters) довольно ясно о том, что вы можете найти при профилировании приложения. Вы можете контролировать счетчики, используя приложение perfmon, встроенное в Windows.

Кроме этого, я бы посоветовал узнать об объединении соединений ADO.NET. Если вы действительно подозреваете ошибку в своем коде, вы можете взглянуть на нее, используя Red Gate's Reflector (бесплатно на данный момент), которая разбирает MSIL в C#.

Answer 4

Я столкнулся с этой проблемой и нашел, что SQL Server Profiler является отличным инструментом, я проверил сайт в ходе короткого тестирования и заметил множество создаваемых соединений (sp_who), которые не были повторно использованы пулом соединений, поэтому я только что открыл SQL Server Profiler, а затем проверить, были ли все вызовы SP, сделанные из кода, вызовом «sp_reset_connection». Если вызова нет до начала новой партии, у вас просто отсутствует первое соединение.

Answer 5

Todd Denlinger написал фантастический класс http://www.codeproject.com/KB/database/connectionmonitor.aspx, который следит за подключением сервера Sql и сообщает о тех, которые не были правильно размещены в течение определенного периода времени. Подключите его к вашему сайту, и он сообщит вам, когда произойдет утечка.

Answer 6

Обнаружена эта тема, исследующая подобную проблему. Я придумал следующий SQL как хороший способ для отладки негерметичных соединений в SQL Server:

SELECT S.spid, login_time, last_batch, status, hostname, program_name, cmd, 
(
     select text from sys.dm_exec_sql_text(S.sql_handle) 
) as last_sql 
FROM sys.sysprocesses S 
where dbid > 0 
and DB_NAME(dbid) = '<my_database_name>' 
and loginame = '<my_application_login>' 
order by last_batch asc 

Что это дает вам это все открытые соединения на конкретной базе данных и входа в систему, вместе с последним SQL, выполняемой на том, что соединение, отсортированное по времени выполнения этого sql.

Из-за пула соединений вы не можете просто полагаться на то, что существует множество соединений, висящих вокруг, чтобы сказать вам, что у вас есть утечка соединения, потому что объединение пулов будет поддерживать соединения даже если они закрыты правильно от кода. Однако, если у вас есть утечка соединения, то вы увидите, что некоторые соединения становятся «замороженными» - они будут отображаться в вышеуказанном запросе, а временная метка «last_batch» никогда не изменится. Другие соединения также будут перемещаться, но каждый раз, когда на них запускается новый sql, метка «last_batch» обновляется. Таким образом, эффект заключается в том, что замороженные соединения будут всплывать в верхней части этого запроса.

Если у вас есть исходный код рассматриваемого приложения, то тот факт, что это дает вам последний sql, выполненный в сиротском соединении, очень ценен для отладки.