2011-01-05 41 views
5

Hiện tại chúng tôi có một chút tình huống trên tay - có vẻ như ai đó, ở đâu đó quên đóng kết nối trong mã. Kết quả là nhóm kết nối tương đối nhanh chóng cạn kiệt. Là một bản vá tạm thời, chúng tôi đã thêm Max Pool Size = 500; vào chuỗi kết nối của chúng tôi trên dịch vụ web và tái chế nhóm khi tất cả các kết nối được chi tiêu, cho đến khi chúng tôi tìm ra điều này.Tất cả các kết nối trong hồ bơi đang được sử dụng

Cho đến nay chúng tôi đã làm điều này:

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

để có được của SPID không được sử dụng trong 15 phút. Hiện chúng tôi đang cố gắng để có được những truy vấn đã được thực hiện cuối cùng sử dụng mà SPID với:

DBCC INPUTBUFFER(61) 

nhưng các truy vấn hiển thị là khác nhau, có nghĩa là một trong hai điều gì đó về mức độ cơ bản về thao tác kết nối bị hỏng, hoặc khấu trừ của chúng tôi là sai lầm. ..

Có lỗi trong suy nghĩ của chúng tôi ở đây không? Liệu các DBCC/sysprocesses cho kết quả chúng ta đang mong đợi hay có một số tác dụng phụ bắt được? (Ví dụ, các kết nối trong ảnh hưởng hồ bơi?)

(xin vui lòng, dính với những gì chúng ta có thể tìm hiểu cách sử dụng SQL từ những kẻ đó đã mã rất nhiều và không phải tất cả có mặt ngay bây giờ)

+3

'những người đã làm mã rất nhiều và không phải tất cả hiện tại ngay bây giờ' .. Tôi không nghĩ rằng họ đã có tất cả khi họ quên đóng kết nối SQL của họ. ;) –

+0

bạn có mã nguồn phải không? Nó không phải là khó khăn để tìm kiếm tất cả các kết nối mở và đóng chúng, miễn là họ không cố tình đi qua các kết nối xung quanh ... –

+1

@will @mitch - bạn * không * muốn xem mã, tin tôi đi :) nhưng, cuối cùng, đó là lựa chọn duy nhất ở cuối ... và chúng tôi đã khắc phục nó bằng cách đặt thử cuối cùng {close} ở mọi nơi ... – veljkoz

Trả lời

2

Tôi hy vọng rằng có vô số các truy vấn khác nhau 'được nhớ' bởi inputbuffer - tùy thuộc vào thời gian thất bại của bạn và nhiều truy vấn bạn chạy, có vẻ như bạn không thấy các truy vấn nhất quán theo cách này. Nhớ lại rằng các kết nối cuối cùng sẽ được đóng lại, nhưng chỉ khi chúng được GC và hoàn thành.

Như Mitch gợi ý, bạn cần phải tìm nguồn gốc của bạn để mở kết nối và đảm bảo chúng được bản địa hóa và được bao bọc bằng cách sử dụng(). Ngoài ra, hãy tìm các đối tượng có thể tồn tại lâu dài có thể đang giữ liên kết. Trong phiên bản đầu tiên của các đối tượng trang ASP của chúng tôi, các đối tượng được tổ chức đã không được quản lý đúng cách.

Để thu hẹp, bạn có thể theo dõi số lượng kết nối (perfmon) khi bạn tập trung vào các phần cụ thể của ứng dụng không? Điều đó có xảy ra nhiều hơn trong các khu vực CRUD so với báo cáo hoặc các truy vấn khác không? Điều đó có thể giúp thu hẹp nguồn-scour bạn cần phải làm.

+0

Sau khi frantically đi qua mã và đặt ở khắp mọi nơi 'cố gắng - cuối cùng {conn.Close()}' chúng tôi quản lý để lưu vấn đề ... thiết kế của lớp điều khiển chống mô hình là (** là **) một kinh dị ... sẽ có sự đánh vào buổi sáng chắc chắn;) cảm ơn mọi người ... – veljkoz

+0

@Mitch: Nếu đó là kết nối DB của .NET thì finalizer sẽ gọi vứt bỏ sẽ giải phóng tài nguyên không được quản lý. Nó chỉ xảy ra tại một thời điểm không xác định bởi vì thời gian GC. – n8wrl

+0

@veljkoz: Bạn có thể biết điều này, nhưng bạn có thể lưu một số cách gõ bằng cách gói các kết nối của bạn bằng cách sử dụng() các khối có hiệu quả làm thử/cuối cùng cho bạn. – n8wrl

1

Bạn có thể thay đổi chuỗi kết nối để chứa thông tin về vị trí và lý do kết nối được tạo trong trường Ứng dụng không?

+0

Tôi không chắc ý bạn là gì?Bạn có thể đưa ra một ví dụ? – veljkoz

+1

Bạn có thể cung cấp thuộc tính "Tên ứng dụng" lên 128 ký tự được hiển thị trong SQL - điều này có thể làm cho việc gỡ rối kết nối dễ dàng hơn nhiều (ở mỗi vị trí duy nhất trong ứng dụng nơi kết nối được tạo sử dụng tên khác). Xem http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnection.connectionstring.aspx. –

Các vấn đề liên quan