Alle Verbindungen im Pool sind in Verwendung

Wir haben derzeit eine kleine Situation in unseren Händen - es scheint, dass jemand, irgendwo vergessen, die Verbindung in Code zu schließen. Das Ergebnis ist, dass der Pool von Verbindungen relativ schnell erschöpft ist. Als temporärer Patch haben wir Max Pool Size = 500; zu unserer Verbindungszeichenfolge im Webservice hinzugefügt und den Pool wiederverwendet, wenn alle Verbindungen verbraucht sind, bis wir das herausgefunden haben.Alle Verbindungen im Pool sind in Verwendung

Bisher haben wir dies getan:

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

SPID ist zu erhalten, die 15 Minuten lang nicht verwendet werden. Wir versuchen nun die Abfrage zu erhalten, die zuletzt, dass SPID mit der Verwendung ausgeführt wurde:

DBCC INPUTBUFFER(61)

aber die angezeigten Abfragen sind vielfältig, was bedeutet, entweder etwas auf Basisebene bezüglich Verbindung Manipulation war gebrochen, oder unser Abzug fehlerhaft ist. ..

Gibt es einen Fehler in unserem Denken hier? Liefern die DBCC/Sysprocesses Ergebnisse, die wir erwarten, oder gibt es Nebeneffekte? (Zum Beispiel Verbindungen im Pool Einfluss?)

(bitte halten, was wir mit SQL herausfinden konnten, da die Jungs, die den Code taten es viele und nicht alle Anwesenden jetzt)

Quelle

2011-01-05 veljkoz

'die Leute, die den Code gemacht haben, sind viele und nicht alle gegenwärtig '.. Ich glaube nicht, dass sie alle da waren, als sie vergaßen, ihre SQL-Verbindungen zu schließen. ;) –

hast du den Quellcode richtig? Es sollte nicht schwer sein, nach all den Verbindungen zu suchen, die geöffnet und geschlossen werden, vorausgesetzt, dass sie nicht absichtlich Verbindungen herumreichen ... –

@will @mitch - du * willst * nicht auf den Code schauen, vertrau mir :) Aber letztendlich war das die einzige Option am Ende ... und wir haben es behoben, indem wir try-finally {close} überall hin brachten ... – veljkoz

Ich würde erwarten, dass Es gibt eine Vielzahl verschiedener Abfragen, die vom Eingabepuffer "gemerkt" werden. Abhängig vom Zeitpunkt des Fehlers und der Vielzahl der ausgeführten Abfragen ist es unwahrscheinlich, dass auf diese Weise konsistente Abfragen angezeigt werden. Erinnern Sie sich daran, dass die Verbindungen letztendlich geschlossen werden, aber nur wenn sie abgeschlossen und abgeschlossen sind.

Wie Mitch vorschlägt, müssen Sie Ihre Quelle nach Verbindungs-Öffnen durchforsten und sicherstellen, dass sie lokalisiert und in ein using() eingebunden sind. Suchen Sie auch nach möglicherweise langlebigen Objekten, die sich möglicherweise an Verbindungen festhalten. In einer früheren Version unseres Katalogs hielten ASP-Seitenobjekte Verbindungen, die nicht ordnungsgemäß verwaltet wurden.

Sie können die Anzahl der Verbindungen (Perfmon) überwachen, während Sie sich auf bestimmte Teile Ihrer App konzentrieren? Geschieht dies eher in CRUD-Bereichen als im Berichtswesen oder in anderen Fragen? Das könnte dazu beitragen, die Quelle zu minimieren, die Sie tun müssen.

Quelle

2011-01-05 13:12:17 n8wrl

Nachdem wir hektisch durch den Code gegangen sind und überall das 'try - finally {conn.Close()}' geschafft haben, haben wir das Problem behoben ... das Design der Anti-Pattern-Controller-Klasse war (** ist **) ein Horror ... es wird am nächsten Morgen Spanking geben;) Danke an alle ... – veljkoz

@Mitch: Wenn es die DB-Verbindung von .NET ist, ruft der Finalizer dispose auf, was die nicht verwalteten Ressourcen freigibt. Es passiert einfach zu einer unbestimmten Zeit wegen GC-Timing. – n8wrl

@veljkoz: Sie wissen das wahrscheinlich, aber Sie können ein wenig Tipparbeit sparen, indem Sie Ihre Verbindungen in() Blöcke einbetten, die effektiv versuchen/endlich für Sie. – n8wrl

Können Sie die Verbindungszeichenfolgen ändern, um Informationen darüber zu enthalten, wo und warum die Verbindung im Feld "Anwendung" erstellt wurde?

Quelle

2011-01-05 13:28:34

Ich bin mir nicht sicher, was du meinst?Kannst du ein Beispiel geben? – veljkoz

Sie können eine "Application Name" -Eigenschaft mit bis zu 128 Zeichen bereitstellen, die in SQL angezeigt wird. Dies kann das Debuggen von Rogue-Verbindungen erheblich vereinfachen (verwenden Sie für jeden eindeutigen Speicherort in der Anwendung, in der die Verbindung erstellt wird, einen anderen Namen). Siehe http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnection.connectionstring.aspx. –

Alle Verbindungen im Pool sind in Verwendung

Antwort

Verwandte Themen