Kết quả NUMA mềm tự động trong số lượng lõi lẻ


7

Tôi đã chạy sp_blitz trên một trong các máy chủ sản xuất SQL Server 2016 của chúng tôi và một trong những phát hiện là có các CPU có số lượng lõi lẻ. Thông báo chi tiết cho biết đây là cấu hình NUMA thực sự xấu.

SQL Server 2016 sẽ sử dụng NUMA mềm tự động nếu phát hiện bộ xử lý vật lý có hơn 8 lõi. Máy chủ cụ thể của chúng tôi có hai ổ cắm với 10 CPU cho mỗi ổ cắm.

Các thông báo khởi động trong nhật ký lỗi SQL Server chỉ ra:

Soft-NUMA tự động đã được bật vì SQL Server đã phát hiện các nút NUMA phần cứng có lớn hơn 8 lõi vật lý.

Kết quả là SQL Server đã tạo ra bốn nút NUMA logic với 5 lõi mỗi nút.

Đây có phải là một vấn đề hiệu suất?

Chúng tôi đang sử dụng MAXDOP = 4.

Là song song một vấn đề ở đây?

Câu trả lời:


3

Chúng tôi không thể trả lời câu hỏi của bạn về "Có vấn đề về hiệu suất không?" Chỉ có bạn mới có thể trả lời điều đó. Bạn có nhận được hiệu suất chấp nhận được trong sản xuất? Tôi có thể nói với bạn rằng tôi biết về một hệ thống sản xuất có hiệu năng chấp nhận được với bốn ổ cắm 10 CPU, mỗi CPU được kích hoạt tự động mềm, vì vậy không thể có được nhu cầu hiệu năng chấp nhận được với các nút NUMA mềm có một số lẻ số lượng lịch trình.

Nếu bạn nghi ngờ rằng sẽ có hiệu suất tăng bằng cách thay đổi cấu hình NUMA của mình thì bạn nên xem xét thử nghiệm điều đó. Theo như tôi biết thì thực sự tất cả phụ thuộc vào khối lượng công việc của bạn. Ba lựa chọn mà bạn có là giữ tự động mềm-NUMA, vô hiệu hóa tự động mềm-NUMA hoặc thử cấu hình thủ công với CPU khử liên kết hoặc làm mềm thủ công-NUMA bằng cách thay đổi sổ đăng ký. Tôi không chắc mình có tất cả các chi tiết ngay bên dưới không nhưng bạn có thể tìm thấy thông tin về những thay đổi trong SQL Server khi bạn thay đổi cấu hình của mình sẽ hữu ích.

Số lượng người viết lười biếng được xác định bởi số lượng nút NUMA vật lý, vì vậy, NUMA mềm sẽ không thay đổi nó. Bạn có thể có tối đa bốn người viết nhật ký giao dịch trong SQL Server 2016, với một nút trên mỗi nút NUMA trong máy chủ SQL. Những người viết nhật ký giao dịch đó sẽ không được trải đều trên các nút NUMA của bạn: chúng được gán cho CPU 1, 2, 3 và 4 khi cần. Bạn sẽ có một trình giám sát tài nguyên cho mỗi nút NUMA logic. Tôi tin rằng bạn cũng sẽ có 1 luồng hoàn thành I / O cho mỗi nút NUMA logic, nhưng tôi chưa xem xét cụ thể về điều đó và không biết liệu có giới hạn nào không.

Có lẽ đi qua một vài cấu hình ví dụ sẽ giúp. Giả sử bạn vô hiệu hóa tự động mềm-NUMA. Đối với cấu hình đó, bạn sẽ có 2 nút NUMA logic gồm 10 bộ lập lịch trong SQL Server, 2 trình giám sát tài nguyên, 2 trình soạn thảo lười biếng, 2 luồng hoàn thành I / O và 2 trình ghi nhật ký giao dịch. Bạn sẽ không còn thấy việc sp_blitztìm kiếm.

Bây giờ, giả sử bạn kích hoạt tự động mềm-NUMA. Đối với cấu hình đó, bạn sẽ có 4 nút NUMA logic gồm 5 trình lập lịch trong SQL Server, 4 trình giám sát tài nguyên, 2 trình soạn thảo lười biếng, 4 luồng hoàn thành I / O và 4 trình ghi nhật ký giao dịch.

Với soft-NUMA thủ công, bạn có thể làm một số thứ như tạo 3 nút NUMA mềm gồm 2 bộ lập lịch, 4 bộ lập lịch và 4 bộ lập lịch cho mỗi ổ cắm. Điều đó cũng sẽ tránh được sp_blitzviệc tìm kiếm. Bạn cũng có thể làm cho 2 CPU trên mỗi ổ cắm không hiển thị với SQL Server trong trường hợp bạn có 8 bộ lập lịch cho mỗi ổ cắm và tự động mềm - NUMA sẽ không áp dụng. Cả hai âm thanh đó giống như cấu hình khá kỳ lạ đối với tôi.

Vì vậy, cấu hình nào là phù hợp nhất cho khối lượng công việc của bạn? Khối lượng công việc của bạn sẽ được hưởng lợi từ việc có 4 người viết nhật ký giao dịch thay vì 2? Khối lượng công việc của bạn sẽ bị tổn hại khi có 4 màn hình tài nguyên thay vì 2? Tôi không có ý kiến. Tất cả những gì bạn có thể làm là điểm chuẩn nó. Tôi chưa thể tìm thấy bất kỳ thông tin nào từ Microsoft khi tự động mềm-NUMA có thể gây hại cho hiệu suất. Quan điểm của họ dường như là nó thường cải thiện hiệu suất và khả năng mở rộng và để nó tiếp tục trừ khi bạn gặp vấn đề về hiệu suất. IMO gửi MAXDOP 4 truy vấn tới 4 nút NUMA mềm của 5 bộ lập lịch không có vẻ gì xấu đối với tôi cả.

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.