Tôi chịu trách nhiệm về một ứng dụng của bên thứ ba (không có quyền truy cập vào nguồn) chạy trên IIS và SQL Server 2005 (500 người dùng đồng thời, dữ liệu 1TB, 8 máy chủ IIS). Gần đây chúng tôi đã bắt đầu thấy sự chặn đáng kể trên cơ sở dữ liệu (sau nhiều tháng chạy ứng dụng này trong sản xuất mà không có vấn đề gì). Điều này xảy ra vào khoảng thời gian ngẫu nhiên trong ngày, khoảng mỗi 30 phút và ảnh hưởng từ 20 đến 100 phiên mỗi lần. Tất cả các phiên cuối cùng đều đạt thời gian đăng ký và các phiên bị hủy bỏ.Vấn đề chặn SQL Server 2005 (ASYNC_NETWORK_IO)
Sự cố biến mất và sau đó dần dần xuất hiện trở lại. Các SPID chịu trách nhiệm về việc ngăn chặn luôn có các tính năng sau:
- WAIT TYPE = ASYNC_NETWORK_IO
- các SQL được chạy được “(@claimid varchar (15)) SELECT claimID, enrollid, trạng thái, orgclaimid, gửi lại, xác nhận quyền sở hữu từ xác nhận quyền sở hữu WHERE primaryclaimid = @claimid AND tuyên bố chính <> claimid) ”. Đây là SQL tương đối vô hại nên chỉ trả lại một hoặc hai bản ghi, không phải là một tập dữ liệu số lớn.
- KHÔNG CÓ câu lệnh SQL nào khác là liên quan đến việc chặn, chỉ câu lệnh SQL này.
- Đây là SQL được tham số hóa mà gói thực hiện được lưu trong bộ nhớ cache trong sys.dm_exec_cached_plans.
- SPID này có khóa S ở mức đối tượng trên bảng xác nhận quyền sở hữu, do đó tất cả UPDATEs/INSERTs cho bảng xác nhận quyền sở hữu cũng bị chặn.
- ID HOST khác nhau. Các máy chủ web khác nhau chịu trách nhiệm về các phiên chặn. Ví dụ, đôi khi chúng ta tìm lại lên máy chủ web 1, đôi khi web server 2.
Khi chúng tôi theo dõi lại cho máy chủ web liên quan đến việc ngăn chặn, chúng ta thấy như sau:
- luôn một số có loại lỗi liên quan đến ứng dụng trong Nhật ký sự kiện trên máy chủ web, được liên kết với ID máy chủ lưu trữ và ID tiến trình máy chủ từ phiên SQL.
- Thông báo lỗi khác nhau, thường là một số loại loại SystemOutofMemory. (Những thông báo lỗi dường như là tương tự như thông báo lỗi mà chúng ta đã thấy trong quá khứ mà không như vậy kịch hậu quả. Chúng tôi nghĩ rằng đã xảy ra trước đó, nhưng không dẫn đến ngăn chặn. Tại sao bây giờ?)
- Không có sự cố nào xảy ra với mạng bộ điều hợp trên máy chủ web hoặc máy chủ SQL.
(Trong mọi trường hợp các thiết lập kỷ lục được trả về bởi truy vấn vi phạm sẽ nhỏ.)
Những điều loại trừ khả năng:
- Chỉ số thường xuyên chống phân mảnh.
- Thống kê được cập nhật thường xuyên.
- Tăng kích thước mẫu thống kê trên claim.primaryclaimid.
- Buộc biên dịch lại gói lưu trữ được lưu trong bộ nhớ cache.
- Tạo chỉ mục hợp chất với xác nhận quyền sở hữu chính, được xác nhận quyền sở hữu.
- Không có sự cố mạng.
- Không có sự cố đã biết trên máy chủ web.
- Không có thay đổi nào đối với phần mềm ứng dụng trên máy chủ web.
Chúng tôi đưa ra giả thuyết rằng các chuỗi sự kiện đi một cái gì đó như thế này:
- quá trình máy chủ Web nộp SQL trên.
- Máy chủ SQL thực thi SQL, trong mà nó mua lại một khóa trên bảng xác nhận quyền sở hữu .
- Quy trình máy chủ web gặp lỗi và chết.
- Phiên máy chủ SQL đang chờ treo để quy trình máy chủ web đọc tập dữ liệu.
- SQL Server phiên cần phải nhận được ổ khóa X trên các bộ phận của bảng tuyên bố (tuyên bố bất cứ ai chế biến) là chặn bởi các khóa trên bảng tuyên bố và vẫn bị chặn cho đến khi họ tất cả nhấn thời gian ứng dụng ra.
Bất kỳ đề xuất khắc phục sự cố nào trong khi chờ hỗ trợ của nhà cung cấp sẽ được chào đón nhiều nhất.
Có cách nào để buộc SQL Server khóa ở cấp hàng/trang cho câu lệnh SQL cụ thể này không? Có cách nào để đặt ngưỡng trên ASYNC_NETWORK_IO chỉ đợi không?
Cảm ơn bạn đã phản hồi nhanh chóng và có nhiều thông tin. Chúng tôi kiểm tra lại các adapter/kết nối mạng vật lý trên tất cả các máy chủ web và tin rằng chúng tôi có thể loại trừ điều này. Câu lệnh SQL có liên quan đến việc chặn thường sẽ trả về một tập dữ liệu rất nhỏ (tối đa 3 bản ghi), không đủ để tràn bộ đệm mạng và tạo ra sự chờ đợi ASYNC_NETWORK_IO kéo dài. Tuy nhiên, có điều kiện biên (@claimid = '') sẽ trả về hàng triệu bản ghi. Điều này rất có thể gây ra ASYNC_NETWORK_IO, ngay cả trên một máy chủ web được cấu hình đúng. Đây là những gì chúng tôi sẽ theo đuổi tiếp theo. – ivankolo