Brent Ozar, Thạc sĩ được chứng nhận của Microsoft gần đây đã thảo luận về tính song song trong SQL Server, đặc biệt là các kiểu chờ CXPACKET và CXCONSUMER trong phần cuối cùng của Quest’s Database Training Days Fall Series. Theo phong cách hài hước và dễ tiếp cận thông thường của mình, Brent đã làm sáng tỏ các khái niệm về song song và giải thích cách xử lý khi bạn thấy quá nhiều thống kê chờ CXPACKET và CXCONSUMER.
Đầu tiên, song song là gì và tại sao SQL Server thực hiện các truy vấn thực thi song song?
Nói một cách đơn giản, SQL Server tự động nhận ra rằng một truy vấn cụ thể có khối lượng công việc lớn và nó xác định rằng công việc có thể được thực hiện hiệu quả hơn trên nhiều bộ xử lý thay vì chỉ một bộ xử lý. Đây thường là một quyết định thông minh, nhưng nó có thể gặp rắc rối khi Máy chủ SQL không cân bằng tải trên các chuỗi thực hiện tác vụ.
Hiểu các kiểu chờ CXPACKET và CXCONSUMER
CXPACKET và CXCONSUMER là các kiểu chờ cho biết rằng công việc không cân bằng như nhau. Khi bạn thấy các số liệu thống kê chờ này trên máy chủ của mình, bạn sẽ biết rằng SQL Server đang chạy các truy vấn song song, nhưng không thực hiện tốt việc phân phối chúng trên các bộ xử lý có sẵn.
Mọi chuyên gia cơ sở dữ liệu đều quen thuộc với khái niệm “chi phí” để thể hiện mức độ tốn kém của một truy vấn để thực thi trong điều kiện tiêu thụ tài nguyên. Những “tiền truy vấn” này là thước đo công việc gần đúng và là tín hiệu quan trọng về việc liệu truy vấn có chạy song song hay không. Một truy vấn rẻ tiền sẽ không cần phải chạy song song, nhưng một truy vấn đắt tiền thì sẽ. Mục tiêu là thực hiện truy vấn nhanh nhất và hiệu quả nhất có thể để truy vấn tiếp theo trong dòng có thể bắt đầu. SQL Server chỉ định một tiểu trình làm bộ lập lịch và tiểu trình này, mà Brent coi là “kẻ thống trị người máy”, sẽ chỉ định các phần của khối lượng công việc song song cho các luồng công nhân hoặc “tay sai của người máy”.
Chủ nghĩa song song và người máy bao trùm
Brent đã đi sâu vào một bản trình diễn để cho thấy điều này hoạt động như thế nào. Bằng cách sử dụng cơ sở dữ liệu Stack Overflow, anh ấy đã tạo ra một bản tra cứu cơ sở dữ liệu chi phí thấp, rất nhanh chóng vì sự hiện diện của một chỉ mục. Kế hoạch thực thi khá đơn giản và không yêu cầu chạy song song.
Tuy nhiên, khi anh ấy giới thiệu cách tra cứu thứ gì đó không có trong chỉ mục, mọi thứ đã thay đổi bằng cách buộc phải tra cứu khóa cho mọi hàng trên chỉ mục nhóm của bảng. SQL Server nhận ra đây sẽ là rất nhiều công việc, vì vậy nó đã đưa ra tính năng song song và được chỉ định như vậy bằng một biểu tượng trên kế hoạch thực thi. Nếu kế hoạch thực thi là ba chiều, bạn có thể thấy nhiều luồng được xếp chồng lên nhau, nhưng vì không phải vậy, bạn cần xem thống kê để xem thông tin chẳng hạn như các lần đọc logic được thực hiện bởi mỗi luồng CPU.
Tuy nhiên, SQL Server chỉ giao nhiệm vụ này cho một vài luồng, không phải tất cả chúng. Brent giải thích rằng mọi thứ xảy ra ngoài biểu tượng song song chỉ xảy ra trên các bộ xử lý được chỉ định. Vì vậy, các luồng đã thực hiện các lần đọc ban đầu hiện là những luồng duy nhất cũng thực hiện việc tra cứu khóa. Lãnh chúa robot chỉ yêu cầu một vài tay sai thực hiện toàn bộ nhiệm vụ thay vì yêu cầu tất cả các tay sai tham gia.
Anh ấy tiếp tục giải thích rằng SQL Server phải tính đến những gì mà các luồng đang làm cũng như theo dõi những gì mà lãnh chúa robot đang làm. Trong những ngày đầu, tất cả công việc này được thể hiện bằng một thống kê chờ, nhưng điều này không có ý nghĩa vì dù thế nào đi nữa, lãnh chúa vẫn phải đợi trong khi tất cả các chuỗi đang hoạt động. Vì vậy, một kiểu chờ mới đã được giới thiệu - đây là CXCONSUMER và nó theo dõi những gì luồng lập lịch / overlord đang làm, trong khi CXPACKET theo dõi những luồng worker / minion đang làm.
Brent quay lại truy vấn để làm cho nó phức tạp hơn bằng cách thêm một loại. Bây giờ, nó trở nên rõ ràng hơn rằng song song đang gây ra một vấn đề hơn là làm cho hoạt động hiệu quả hơn. Công việc thậm chí còn trở nên mất cân bằng hơn trên một số luồng công nhân, và một số đang hết bộ nhớ và tràn ra đĩa. Anh ấy đã thêm một tham gia, thậm chí còn tạo thêm gánh nặng cho các lõi hoạt động không nhận được bất kỳ sự hỗ trợ nào từ các lõi không hoạt động. Các chỉ số của CXPACKET tiếp tục tăng.
Bạn có thể làm gì trong tình huống này? Quyết định song song đang xảy ra ở cấp máy chủ chứ không phải ở cấp truy vấn, vì vậy sẽ thực hiện một số thay đổi về cấu hình.
Đánh giá cấu hình chính
Chúng ta đã biết rằng nếu chi phí truy vấn cao hơn một mức nhất định, nó sẽ làm cho SQL Server chạy song song. Các truy vấn nhỏ bị giới hạn trong một luồng duy nhất. Nhưng điều gì kiểm soát ngưỡng? Đó là một thuộc tính được gọi là Ngưỡng chi phí cho song song (CTFP). Theo mặc định, nếu kế hoạch thực thi xác định chi phí cao hơn 5 đô la truy vấn, truy vấn sẽ được song song hóa. Mặc dù không có hướng dẫn về cách đặt điều này, Brent đề xuất một số lớn hơn 50. Điều này sẽ loại bỏ tính song song đối với các truy vấn tầm thường.
Một cấu hình khác là mức độ song song tối đa (MAXDOP) mô tả số luồng mà SQL Server sẽ gán cho truy vấn. Giá trị mặc định ở đây là 0, có nghĩa là SQL Server có thể sử dụng tất cả các bộ xử lý có sẵn, lên đến 64, để thực hiện truy vấn. Đặt tùy chọn MAXDOP thành 1 giới hạn SQL Server chỉ sử dụng một bộ xử lý - có hiệu lực, buộc một kế hoạch nối tiếp thực hiện truy vấn. SQL Server sẽ đề xuất giá trị MAXDOP dựa trên số lõi máy chủ mà bạn có, nhưng nhìn chung, MAXDOP thấp hơn có ý nghĩa vì sẽ không có nhiều lần tất cả các lõi đều cần thiết.
Brent đã thực hiện các điều chỉnh đối với hai cấu hình này và chạy lại truy vấn của mình. Lần này, chúng ta có thể thấy rằng nhiều lõi hơn đã tham gia vào hoạt động song song. Số liệu thống kê về thời gian chờ của CXPACKET thấp hơn, có nghĩa là tải được cân bằng đồng đều hơn trên nhiều lõi hơn trước.
Mẹo để chống lại số liệu thống kê chờ CXPACKET và CXCONSUMER
Brent đề xuất các bước sau nếu bạn thấy thống kê chờ CXPACKET và CXCONSUMER quá nhiều:
- Đặt CTFP và MAXDOP theo các phương pháp hay nhất trong ngành và sau đó để các cài đặt đó hoàn thiện trong vài ngày. Thao tác này sẽ xóa bộ nhớ cache của kế hoạch và buộc SQL Server phải xây dựng lại kế hoạch thực thi truy vấn (đánh giá lại chi phí).
- Thực hiện các cải tiến về chỉ mục để giảm thời gian các truy vấn song song với việc quét và sắp xếp. Hãy để các chỉ mục mới thành công và sau đó tìm kiếm các truy vấn vẫn đang hoạt động nhiều.
- Điều chỉnh các truy vấn đó và để chúng nướng trong vài ngày.
- Cuối cùng, nếu vấn đề song song vẫn là một vấn đề nghiêm trọng, hãy bắt đầu tìm các truy vấn cụ thể có vấn đề về song song.
Để có thêm thông tin chi tiết, bạn có thể xem toàn bộ buổi đào tạo của Brent trên CXPACKET và số liệu thống kê về thời gian chờ của CXCONSUMER theo yêu cầu bên dưới.
