2011-01-05 14 views
5

Actualmente tenemos una pequeña situación en nuestras manos, parece que alguien, en algún lugar se olvidó de cerrar la conexión en el código. El resultado es que el grupo de conexiones se agota relativamente rápido. Como un parche temporal agregamos Max Pool Size = 500; a nuestra cadena de conexión en el servicio web, y reciclamos la agrupación cuando todas las conexiones se gastan, hasta que nos damos cuenta de esto.Todas las conexiones en el grupo están en uso

Hasta ahora hemos hecho esto:

SELECT SPId 
FROM MASTER..SysProcesses 
WHERE DBId = DB_ID('MyDb') and last_batch < DATEADD(MINUTE, -15, GETDATE()) 

para obtener SPID de que no se utiliza durante 15 minutos. Estamos tratando de que la consulta que se ejecutó el pasado usando ese SPID con:

DBCC INPUTBUFFER(61) 

pero las consultas que se ven son diferentes, es decir, ya sea algo en nivel de base en relación con la manipulación de la conexión se rompió, o nuestra deducción es errónea. ..

¿Hay algún error en nuestro pensamiento aquí? ¿El DBCC/sysprocesses da resultados que esperamos o hay alguna captura de efecto secundario? (Por ejemplo, conexiones en la influencia de la piscina?)

(por favor, se adhieren a lo que pudimos encontrar a cabo utilizando SQL ya que los chicos que hicieron el código son muchos y no todos los presentes en este momento)

+3

'los chicos que hicieron el código son muchos y no todos están presentes ahora mismo ... no creo que estuvieran todos allí cuando olvidaron cerrar sus Conexiones SQL. ;) –

+0

tiene el código fuente correcto? No debería ser difícil buscar todas las conexiones que se abren y cerrarlas, siempre que no estén pasando deliberadamente conexiones alrededor de ... –

+1

@will @mitch - usted * no * quiere ver el código, créame :) pero, eventualmente, esa fue la única opción al final ... y lo solucionamos poniendo try-finally {close} en todas partes ... – veljkoz

Respuesta

2

yo esperaría que Hay una gran cantidad de consultas diferentes 'recordadas' por inputbuffer: dependiendo del momento de su falla y la variedad de consultas que ejecuta, parece poco probable que usted vea consultas consistentes de esta manera. Recuerde que las conexiones eventualmente se cerrarán, pero solo cuando estén finalizadas y aprobadas por GC.

Como sugiere Mitch, debe buscar en su fuente de conexión-se abre y asegurarse de que estén localizados y envueltos en un uso(). También busque objetos posiblemente de larga vida que puedan estar retenidos en las conexiones. En una versión anterior de nuestro catálogo, los objetos de la página ASP contenían conexiones que no se administraban correctamente.

Para reducirlo, ¿puede supervisar los recuentos de conexión (perfmon) a medida que se enfoca en partes específicas de su aplicación? ¿Sucede más en áreas de CRUD frente a informes u otras consultas? Eso podría ayudar a reducir la fuente de socorro que necesita hacer.

+0

Después de pasar frenéticamente por el código y poner en todas partes el 'try - finally {conn.Close()}' logramos salvar el problema ... el diseño de la clase de controlador anti-patrón fue (** is **) un horror ... habrá zurras por la mañana, eso es seguro;) gracias a todos ... – veljkoz

+0

@Mitch: si se trata de la conexión DB de .NET, el finalizador llamará a disponer, lo que liberará los recursos no administrados. Simplemente sucede en un tiempo indeterminado debido a la sincronización del GC. – n8wrl

+0

@veljkoz: Es probable que lo sepas, pero puedes guardar algo de tipeado envolviendo tus conexiones en el uso de() bloques que efectivamente hacen el intento/finalmente por ti. – n8wrl

1

¿Puede cambiar las cadenas de conexión para que contengan información sobre dónde y por qué se creó la conexión en el campo Aplicación?

+0

No estoy seguro de lo que quieres decir?¿Podría dar un ejemplo? – veljkoz

+1

Puede proporcionar una propiedad de "Nombre de aplicación" de hasta 128 caracteres que se muestra en SQL; esto puede facilitar mucho más la depuración de conexiones fraudulentas (en cada ubicación única de la aplicación donde se crea la conexión, use un nombre diferente). Consulte http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnection.connectionstring.aspx. –

Cuestiones relacionadas