Điều tra sự chờ đợi SQL cao, đặc biệt là LCK_M_U


7

Gần đây tôi đã phải vật lộn với hiệu suất máy chủ SQL và mặc dù chúng tôi đã sửa rất nhiều lỗi cơ bản trong cấu hình nhưng nó vẫn hoạt động kém. Để làm rõ nó không phải là hiệu suất tổng thể mà là thời gian chờ khá thường xuyên (từ ứng dụng khách). Trước đây tôi đã xem bộ nhớ là một nguyên nhân nhưng bây giờ điều này đã được giải quyết và chúng tôi vẫn đang có hành vi tương tự.

Nhìn vào các biểu đồ từ Kho dữ liệu quản lý, tôi có thể thấy rằng LCK_M_U / X / IX đang gây ra phần lớn sự chờ đợi của chúng tôi trong khoảng thời gian người dùng trải qua thời gian chờ. Tất cả mọi thứ tôi đang đọc trạng thái tôi cần xem xét các truy vấn và quy trình đang chạy nhưng tôi vẫn chưa tìm thấy bất cứ điều gì nhắm đến mức tôi có thể hiểu. Các khóa, như bạn có thể thấy trong hình bên dưới, dường như tăng đột biến trùng khớp với lỗi ở phía người dùng. Có một DMV thông minh hoặc một số như vậy mà tôi có thể giải quyết để thử và tìm ra truy vấn nào đang được chạy đang tạo khóa không? Đây có phải là một trường hợp truy tìm thông qua một dấu vết để tìm các chi tiết? Bất kỳ hướng dẫn đánh giá rất cao và xin lỗi nếu thông tin không rõ ràng.

nhập mô tả hình ảnh ở đây


1
Những loại cơ sở dữ liệu trên máy chủ này? Nó là một cơ sở dữ liệu duy nhất, hoặc nhiều? Các mẫu truy cập (OLTP / DW) là gì? Phản ứng ban đầu của tôi là một số phần của ứng dụng đang chạy hoặc đọc lớn (chỉ mục bị thiếu?) Và những người dùng khác phải chờ để thay đổi dữ liệu (còn gọi là chặn). Bài đăng này trên blog của tôi có thể được quan tâm cho nền tảng: tự
nguyệndba.com / post / 2013/01/22 / //

Câu trả lời:


4

Thu thập dữ liệu từ sp_WhoIsActive trong Bảng là một kỹ thuật tốt để theo dõi các vấn đề chặn và khóa.

Các @get_locks tham số có thể được sử dụng nếu bạn muốn xem chi tiết tốt hơn của các ổ khóa có liên quan. Ngoài ra, @get_task_info và @get_additable_info thường sẽ nắm bắt đủ để xác định nguyên nhân.

Nếu đầu ra được thu thập không đủ rõ ràng để hiểu vấn đề, vui lòng thêm vào câu hỏi của bạn.


7

Khóa có xu hướng hình thành chuỗi và bạn luôn quan tâm chủ yếu đến những gì quá trình ở đầu chuỗi đang làm. Chỉ đơn giản là nhìn vào thời gian chờ khóa có thể gây hiểu nhầm vì nhiều quy trình có thể chờ thời gian dài (do đó làm tăng chỉ số thời gian chờ) nhưng tất cả đều bị chặn bởi một quy trình chậm chó. Những gì bạn có thể thấy là một điểm kết hợp: bởi vì các khóa được cấp phải tương thích với tất cả những người được cấp hiện tại và tất cả những người phục vụ đang chờ xử lý bất cứ khi nào khóa cấp cao (X hoặc SCH_M) vào hàng đợi cho một tài nguyên, tất cả các yêu cầu tiếp theo xếp sau .

Để đưa ra một ví dụ: giả sử bạn có một truy vấn đang chạy báo cáo trên bảng, giả sử phải mất 5 phút. Nó giữ một khóa IS không phải bàn. IS này tương thích với tất cả các hoạt động bình thường (đọc ghi). Một yêu cầu đến trong đó muốn SCH_M. Không tương thích với IS nên anh ta xếp hàng. Bây giờ tất cả các hoạt động đột ngột khác trên bàn đều đi vào hàng đợi, bởi vì mọi yêu cầu, đọc hoặc wites, đều không tương thích với người phục vụ này. Vì vậy, tất cả các khóa đột ngột tăng đột biến. Sau 5 phút, truy vấn chậm kết thúc (nó 'thoát' trong thuật ngữ DB), SCH_M được cấp, nó thực hiện công việc của nó trong 5 ms và mọi người khác được tự do tiến hành. Đây chỉ là một ví dụ (cực đoan), nó không phải là SCH_M. Ý tưởng là chỉ chờ thời gian đừng kể toàn bộ câu chuyện.

May mắn thay, chính SQL Server có thể báo cáo các chuỗi chặn cho bạn thông qua một tính năng gần như không xác định được gọi blocked process threshold. Trộn trong Báo cáo quy trình bị chặnthông báo sự kiện DDL và bạn sẽ có được giải pháp hoàn toàn tự động.

Để biết ví dụ, hãy xem câu trả lời của tôi tại các công cụ giám sát chặn giao dịch của bên thứ ba MS SQL Server .

Một quan sát khác: Bạn có 22,30% thời gian chờ đợi trên IX. Điều này ngụ ý một khóa cấp đối tượng xảy ra. Khóa ý định (IS, IX) tương thích, do đó, việc IX bị chặn cho thấy ai đó có được khóa cấp đối tượng không tương thích. Quét có được S, hoặc một bản cập nhật lớn leo thang đến X.


Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.