Come rilevare le perdite di connessione SqlServer in applicazioni ASP.net?

Question

Attualmente sto eseguendo alcuni test della GUI su un'applicazione ASP.net 2.0. RDBMS è SQL Server 2005. L'host è Win Server 2003 / IIS 6.0.

Non ho il codice sorgente dell'applicazione perché è stato programmato da una società esterna che non sta rilasciando il codice.

Ho notato che l'applicazione funziona bene quando riavvio IIS ma dopo alcuni test, dopo aver aperto e chiuso il browser per un paio d'ore, l'applicazione inizia a diventare sempre più lenta. Mi chiedevo se questo comportamento fosse dovuto a una cattiva pratica di chiusura della connessione da parte dei programmatori: sto sospettando una perdita di connessione aperta sul database qui.

Suppongo che il Garbage Collector .Net alla fine li chiuderà, ma ... questo potrebbe richiedere del tempo, no?

Ho SQL Server Management Studio e noto dal monitor delle attività che ci sono alcune connessioni aperte sul database.

Da quanto detto sopra, ecco alcune domande relative alla domanda principale:

1. Esiste un modo per sapere in SQL Server 2005 se le connessioni sono aperto perché stanno aspettando di essere utilizzato in un pool di connessioni o if sono aperti perché sono usati da un applicazione?

2. Qualcuno sa di bene risorse online / cartacee dove ho potuto scopri come usare le prestazioni contatori o altri tipi di strumenti per aiutare a rintracciare questo tipo di problemi?

3. Se i contatori delle prestazioni sono i migliori soluzione, quali sono le variabili che io dovrebbe guardare?

Answer 1

Puoi sempre controllare le stringhe di connessione da web.config (principalmente se hanno il pool di connessioni attivato, se hanno dei limiti di connessione abilitati).

Inoltre, se si utilizza IIS 6, è possibile impostare l'applicazione Web in modo che utilizzi un pool di applicazioni separato e impostare altre opzioni per il riciclaggio della memoria e dei processi.

Per quanto riguarda i contatori delle prestazioni, puoi verificare per quanto tempo è in esecuzione il Garbage Collector, quanta memoria sta utilizzando l'applicazione, ecc.

Se si ha accesso al server sql, è possibile monitorare le connessioni effettuate dall'applicazione (esistono contatori delle prestazioni definiti per ogni istanza installata di SQL Server).

C'erano alcuni articoli nella MSDN Magazine . Inoltre, è possibile utilizzare la libreria di debug di SOS per collegarsi al processo dell'applicazione e controllarlo manualmente.

E, se non si dispone del codice sorgente, provare a utilizzare Reflector per ottenere i sorgenti dell'applicazione (sarebbero molto utili per il debug)

@Later edit: puoi controllare questa domanda anche qui su stackoverflow.com

Answer 2

Trovato questo thread alla ricerca di un problema simile. Ho trovato il seguente sql come un buon modo per eseguire il debug di connessioni che perdono in 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 loginname = '<my_application_login>'
order by last_batch asc

Ciò che ti dà sono tutte le connessioni aperte su un particolare database e login, insieme all'ultimo sql eseguito su quella connessione , ordinato in base al momento in cui quel sql è stato eseguito.

A causa del pool di connessioni, non puoi semplicemente fare affidamento sul fatto che ci sono molte connessioni in giro per dirti che hai una perdita di connessione, perché il pool di connessioni manterrà le connessioni anche se sono chiuse correttamente dal codice. Tuttavia, se hai una perdita di connessione, vedrai che alcune connessioni diventano & # 8220; congelate & # 8221; & # 8212; verranno visualizzate nella query sopra e & # 8220; last_batch & # 8221; il timestamp non cambierà mai. Anche le altre connessioni rimarranno sospese, ma ogni volta che viene eseguito nuovo sql su di esse, & # 8220; last_batch & # 8221; il timestamp viene aggiornato. Quindi l'effetto è che le connessioni congelate galleggeranno all'inizio di questa query.

Se hai il codice sorgente dell'applicazione in questione, il fatto che questo ti dia l'ultimo sql eseguito sulla connessione orfana è molto prezioso per il debug.

Answer 3

Ho riscontrato questo problema e ho trovato SQL Server Profiler un ottimo strumento, ho monitorato il sito in una breve sessione di test e ho notato che venivano create molte connessioni (sp_who) che non erano state riutilizzate dal pool di connessioni, quindi ho appena aperto SQL Server Profiler, quindi controlla se tutte le chiamate a SP effettuate dal codice sono state seguite da un "sp_reset_connection" chiamata. Se la chiamata non è presente prima dell'inizio di un nuovo batch, manca solo la prima connessione.

Answer 4

Il riferimento MSDN su ( contatori delle prestazioni ADO.NET ) è abbastanza chiaro su cosa puoi cercare quando si profila l'applicazione. Puoi monitorare i contatori usando la perfmon applicazione integrata in Windows.

Oltre a questo, suggerirei di imparare a conoscere il pool di connessioni ADO.NET. Se sospetti davvero un bug nel loro codice, puoi dare un'occhiata a Red Gate's Reflector (gratuito per ora) che disassembla MSIL in C #.

Answer 5

Vorrei iniziare osservando le connessioni e osservando i tempi di attività e vedere se riesci a trovare elementi che mantengono aperte le connessioni.

Direi che se la soluzione fosse riavviare IIS, potresti anche esaminare l'utilizzo della memoria dell'applicazione per vedere se c'è una perdita di memoria o qualcosa che causa davvero la sua impronta di crescita.

Se le connessioni aperte fossero un problema, nel monitor delle attività vedresti un MOLTO numero di connessioni senza attività.

Per i contatori delle prestazioni potresti iniziare a guardare " SQL Server: statistiche generali " oggetto performance.

Answer 6

Todd Denlinger ha scritto una classe fantastica http://www.codeproject.com/KB/ database / connectionmonitor.aspx che controlla le connessioni SQL Server e riporta quelle che non sono state correttamente smaltite entro un periodo di tempo. Collegalo al tuo sito e ti farà sapere quando c'è una perdita.