Trở lại năm 2014, tôi đã bắt đầu một loạt các bài đăng trên blog ở đây để nói về các kiểu chờ đợi cụ thể và những gì chúng làm và không có ý nghĩa. Điều đó đã cho tôi ý tưởng tạo các thư viện chờ và chốt mà tôi duy trì (sẽ tìm hiểu thêm về các thư viện này sau).
Nếu bạn đang đọc nó và nghĩ "anh ấy đang nói về cái gì vậy?" thì bài viết này là dành cho bạn. Tôi sẽ giới thiệu cho bạn các thống kê chờ và giải thích mức độ quan trọng của chúng đối với việc khắc phục sự cố hiệu suất khối lượng công việc trong SQL Server.
Lập lịch
Việc thực thi mã nội bộ của SQL Server được thực hiện bằng cơ chế có tên là luồng . Mỗi luồng có thể đang thực thi mã SQL Server và nhiều luồng phối hợp với nhau khi một truy vấn chạy song song. Các luồng này được tạo khi SQL Server khởi động, tùy thuộc vào số lượng lõi bộ xử lý có sẵn cho SQL Server để sử dụng.
Chủ đề được đặt trên bộ lập lịch khi một truy vấn bắt đầu, với một bộ lập lịch cho mỗi lõi bộ xử lý và không rời bộ lập lịch đó cho đến khi truy vấn kết thúc. Công cụ lập lịch có ba "phần" cơ bản:
- Bộ xử lý , có chính xác một chuỗi hiện đang thực thi mã.
- Danh sách người phục vụ , có tất cả các chuỗi về cơ bản bị kẹt, đang chờ một tài nguyên cụ thể có sẵn.
- Hàng đợi chạy được , có tất cả các chuỗi có thể thực thi nhưng đang chờ để truy cập vào bộ xử lý.
Luồng chuyển đổi từ trạng thái 1 sang 2 sang 3 sang 1, lặp đi lặp lại cho đến khi kết thúc truy vấn.
Chờ đợi
Theo quan điểm của chúng tôi, phần thú vị nhất của việc lập lịch là khi một luồng phải đợi một tài nguyên trước khi nó có thể tiếp tục. Một số ví dụ về điều này là:
- Một chuỗi cần đọc một trang và trang đó không có trong bộ nhớ, vì vậy, chuỗi phát hành I / O vật lý không đồng bộ và sau đó phải đợi tắt bộ xử lý cho đến khi I / O hoàn tất.
- Một chuỗi cần có một khóa chia sẻ trên một hàng để đọc nó, nhưng một chuỗi khác đã giữ một khóa độc quyền xung đột trong khi nó đang cập nhật hàng.
Khi một luồng gặp phải nhu cầu về tài nguyên mà nó không thể lấy được, nó không có lựa chọn nào khác ngoài việc dừng lại và đợi tài nguyên đó khả dụng (cơ chế về cách luồng được thông báo về tính khả dụng của tài nguyên nằm ngoài phạm vi của bài viết này). Khi điều đó xảy ra, SQL Server ghi chú lý do tại sao chuỗi phải đợi và đây được gọi là loại chờ . Một số ví dụ về điều này là:
- Khi một chuỗi đang đợi một trang được đọc vào bộ nhớ để nó có thể được đọc, kiểu chờ là PAGEIOLATCH_SH (nếu chuỗi đang đợi một trang mà nó sẽ thay đổi, thì kiểu chờ là PAGEIOLATCH_EX ).
- Khi một chuỗi đang chờ khóa chia sẻ trên một hàng, kiểu chờ là LCK_M_S (khóa-chế độ-chia sẻ)
SQL Server cũng theo dõi thời gian luồng phải đợi. Đây được gọi là thời gian chờ tài nguyên và thường được gọi là thời gian chờ .
Thống kê Chờ
Tập hợp số liệu tổng thể về số lượng chủ đề đã đợi tài nguyên nào và trong bao lâu trung bình được gọi là thống kê chờ . Thông tin này cực kỳ hữu ích để khắc phục sự cố hiệu suất khối lượng công việc, vì bạn có thể dễ dàng biết vị trí có thể xảy ra tắc nghẽn hiệu suất.
Ý tưởng cơ bản là SQL Server có thông tin về lý do tại sao các luồng phải dừng và chờ cũng như những gì chúng đang chờ đợi. Vì vậy, thay vì phải đoán xem bắt đầu khắc phục sự cố từ đâu, phân tích cẩn thận các thống kê về thời gian chờ thường có thể chỉ cho bạn một hướng đi.
Ví dụ:nếu phần lớn thời gian chờ trên máy chủ là PAGEIOLATCH_SH , điều này có thể cho thấy rằng có áp lực bộ nhớ trên máy chủ hoặc có các truy vấn thực hiện quét bảng lớn thay vì sử dụng các chỉ mục không phân biệt hoặc có vấn đề với hệ thống con I / O bên dưới hoặc một số lý do khác.
Có một số lượng lớn các loại chờ đợi nhưng hầu hết chúng không xuất hiện thường xuyên, vì vậy, có một nhóm cốt lõi mà bạn sẽ thấy nhiều lần trên máy chủ của mình. Hiểu ý nghĩa của những điều này và cách điều tra chúng là rất quan trọng để bạn không bị khuất phục bởi cái mà tôi gọi là 'điều chỉnh hiệu suất giật gân' và lãng phí thời gian và nỗ lực để cố gắng khắc phục một vấn đề thực sự không phải là vấn đề. Tôi đã viết một loạt các bài đăng trên blog đi vào chi tiết ở đây, và Aaron Bertrand cũng đã viết một bài tóm tắt về 10 thống kê chờ đợi hàng đầu vào năm ngoái.
Theo dõi Chờ
Có một số cách mà bạn có thể theo dõi thời gian chờ. Đơn giản nhất là xem những gì đang chờ đang xảy ra trên máy chủ ngay bây giờ, sử dụng tập lệnh kiểm tra sys.dm_os_waiting_tasks DMV. Bạn có thể tìm thấy một tập lệnh để thực hiện điều đó tại đây và có các URL được tạo tự động vào thư viện chờ.
Một cách khác là xem thống kê chờ tổng hợp cho toàn bộ máy chủ, với một tập lệnh kiểm tra sys.dm_os_wait_stats DMV. Bạn có thể tìm thấy một tập lệnh để thực hiện điều đó tại đây và có các URL được tạo tự động vào thư viện chờ. Tuy nhiên, bạn cần phải cẩn thận với phương pháp đó, vì nó sẽ hiển thị tất cả các lần đợi đã xảy ra kể từ khi máy chủ khởi động. Một cách tốt hơn là theo dõi các lần chờ đợi trong những khoảng thời gian nhỏ, chẳng hạn nửa giờ và tập lệnh để thực hiện điều đó ở đây.
Bạn cũng có thể nhận thống kê thời gian chờ bằng cách sử dụng bổ trợ Báo cáo Máy chủ cho công cụ Azure Data Studio mới và sử dụng Cửa hàng truy vấn từ SQL Server 2017 trở đi.
Hãy nhớ rằng, bạn vẫn cần hiểu ý nghĩa của các kiểu chờ đợi sau khi bạn đã thu thập các chỉ số.
Tài nguyên chờ
Để giải quyết vấn đề này và vì Microsoft không có tài liệu về cách giải thích thống kê chờ, vào năm 2016, tôi đã phát hành một thư viện kiểu chờ, với thông tin chi tiết về hàng trăm kiểu chờ phổ biến và cách khắc phục chúng. Bạn có thể truy cập thư viện tại https://www.SQLskills.com/help/waits. Và sau đó vào năm 2017, SentryOne đã tạo ra một hệ thống tự động để cung cấp đồ họa thông tin cho mỗi trang trong thư viện mà bạn có thể nhanh chóng sử dụng để xem liệu kiểu chờ đợi mà bạn quan tâm có thực sự phổ biến hay không (xem bài đăng này để biết chi tiết) . Dưới đây là một đồ họa thông tin ví dụ cho PAGEIOLATCH_SH kiểu chờ:
Trên trục hoành là thang đo (có thể chuyển đổi giữa tuyến tính và logarit) về tỷ lệ phần trăm trường hợp (được SentryOne theo dõi từ xa) đã trải qua thời gian chờ đợi này trong tháng trước đó và trên trục tung là phần trăm thời gian mà các trường hợp đó đã trải qua điều đó chờ đợi thực sự đã có một chuỗi chờ đợi kiểu chờ đợi đó.
Một tài nguyên khác để giúp bạn hiểu về sự chờ đợi là một khóa đào tạo trực tuyến mà tôi đã ghi lại cho Pluralsight - xem tại đây.
Ít nhất, bạn nên đọc qua các bài đăng blog khác nhau trong phần Thống kê Chờ và Theo dõi Thời gian Chờ ở trên.
Theo dõi thời gian chờ bằng công cụ SentryOne
SQL Sentry tự động theo dõi các lần đợi ở cấp độ cá thể cho bạn theo thời gian, vì vậy bạn không phải bắt các lần chờ cao "đang diễn ra". Ai đó phàn nàn về một hệ thống chậm chạp vào chiều hôm qua hoặc một báo cáo đã hết hạn vào thứ Ba tuần trước? Không vấn đề gì. Bạn có thể tìm hiểu tất cả các lần chờ đợi cho bất kỳ thời điểm nào hoặc trong một phạm vi và tương quan chúng với các chỉ số hiệu suất khác được thu thập tại thời điểm - có thể là các xu hướng khác trên trang tổng quan, như sao lưu hoặc hoạt động I / O của cơ sở dữ liệu, chuyển sang tất cả các lệnh SQL hàng đầu đang chạy trong cùng một cửa sổ, điều tra quá trình chặn đã chạy trong thời gian dài hoặc sử dụng các đường cơ sở để so sánh cấu hình chờ với các khoảng thời gian khác.
Bạn thậm chí có thể tùy chỉnh các lần chờ được hoặc không được thu thập, thay đổi các danh mục được trình bày trực quan và xây dựng cảnh báo và / hoặc phản hồi thông minh cho các tình huống chờ cụ thể. Nhiều khách hàng của chúng tôi sử dụng SQL Sentry để tập trung vào các vấn đề hiệu suất thực tế liên quan đến các lần chờ, vì nó cho phép họ bỏ qua rất nhiều tiếng ồn mà chỉ là hoạt động luồng SQL Server bình thường.
Tóm tắt
Như bạn có thể thấy từ thông tin ở trên, việc chờ đợi luôn xảy ra trong SQL Server, vì đó chỉ là cách hoạt động của hệ thống lập lịch luồng và đa luồng. Chúng là một trong những công cụ mạnh mẽ nhất trong hộp công cụ khắc phục sự cố của bạn, vì vậy nếu bạn chưa sử dụng chúng, bây giờ là lúc để bắt đầu. Đường cong học tập ngắn và dốc - khi bạn đã chạy các truy vấn và công cụ khác nhau một vài lần, bạn sẽ nhanh chóng hiểu được nó, và sau đó là trường hợp đọc qua các hướng dẫn cho những chờ đợi bạn đang thấy và xác định xem chúng có phải là vấn đề không.
Chúc bạn gỡ rối thành công!
