Sự khôn ngoan hiện tại trên SQL Server và Hyperthreading?

Có rất nhiều bài viết ngoài đó (xem bài viết SQL 2000 gốc của Slava Oks và bản cập nhật SQL 2005 của Kevin Kline ) khuyên bạn nên vô hiệu hóa siêu phân luồng trên các máy chủ SQL hoặc ít nhất là kiểm tra khối lượng công việc cụ thể của bạn trước khi bật nó trên máy chủ của bạn.

Vấn đề này đang dần trở nên ít liên quan hơn khi các bộ xử lý đa lõi thực sự thay thế các bộ siêu phân luồng, nhưng sự khôn ngoan hiện tại về vấn đề này là gì? Lời khuyên này có thay đổi bất kỳ với SQL 2005 64-bit hoặc SQL 2008 hoặc Windows Server 2008 không?

Lý tưởng nhất, điều này nên được kiểm tra trước trong môi trường dàn dựng, nhưng đối với các máy chủ đã đưa nó vào sản xuất với HT được kích hoạt thì sao? Làm cách nào để biết các vấn đề về hiệu suất mà chúng tôi gặp phải có thể liên quan đến HT? Có một số kết hợp cụ thể của bộ đếm perfmon có thể chỉ cho tôi theo hướng đó, trái ngược với tất cả những thứ khác mà tôi thường theo đuổi khi làm việc để cải thiện hiệu suất SQL?

Chỉnh sửa : Điều này đặc biệt hấp dẫn vì những tiềm năng cho một trên bảng cải thiện cho một số máy chủ CPU cao của tôi, nhưng khách hàng sẽ muốn nhìn thấy một cái gì đó cụ thể đó giúp tôi xác định được máy chủ thực sự có thể được hưởng lợi từ việc vô hiệu hóa hyperthreading. Tất nhiên, xử lý sự cố hiệu suất thông thường đang diễn ra, nhưng đôi khi bất kỳ một chút giúp đỡ.

Trong SQLOS, bộ lập lịch được tạo cho mỗi bộ xử lý logic mà SQL Server nhìn thấy. Với siêu phân luồng được kích hoạt, điều này tương đương với gấp đôi lịch trình. Một trong những mục đích của SQLOS là để giảm thiểu và ngăn chặn chuyển đổi ngữ cảnh xảy ra, đó là lý do tại sao chỉ có một bộ lập lịch được tạo cho mỗi bộ xử lý logic. Khi SQLOS tạo các bộ lập lịch, tổng số công nhân được chia cho các bộ lập lịch. SQLOS thực hiện một hình thức lập lịch hợp tác trong đó các công nhân tạo ra bộ lập lịch vì nó yêu cầu các tài nguyên không có sẵn hoặc đạt đến lượng tử thực thi của nó cho phép các công nhân khác thực hiện trên bộ lập lịch. Điều này giữ cho ngữ cảnh chuyển sang mức tối thiểu vì bộ lập lịch đang thực hiện công việc và chúng bị ràng buộc từng cái một.

Hiểu nền tảng đó, siêu phân luồng phần nào hoạt động ngược lại với cách SQLOS được thiết kế đặc biệt để hoạt động. Cụ thể, tính song song có thể có vấn đề với siêu phân luồng và có thể dẫn đến sự chờ đợi CXPACKET cao vì SQLOS có thể cố gắng chạy truy vấn tại DOP 8 trên thực tế hệ thống DOP 4 là gì. Nếu mức độ sử dụng CPU của bạn thấp, bạn có thể không nhận thấy, nhưng việc sử dụng CPU của bạn càng cao thì càng có nhiều vấn đề. Gần đây tôi đã có một cuộc thảo luận trên twitter về điều này, và sự đồng thuận là "Nó phụ thuộc" vào việc nó sẽ giúp đỡ hay làm tổn thương.

Nếu bạn có nhiều tín hiệu chờ trên máy chủ của mình, nhưng bạn sử dụng CPU thấp, bạn có thể thấy lợi ích cho phép siêu phân luồng sẽ tăng gấp đôi lịch trình nội bộ của bạn và truyền bá công nhân ra nhiều hơn, điều đó có nghĩa là họ sẽ không chờ để thực hiện trong hàng đợi có thể chạy được miễn là Tuy nhiên, nếu khối lượng công việc của bạn sử dụng song song nhiều, bạn sẽ phải chờ đợi CXPACKET nặng trong sys.dm_os_wait_stats, bạn có thể xem xét việc vô hiệu hóa siêu phân luồng để xem liệu nó có làm giảm sự chờ đợi của bạn không.

Trên thực tế, siêu phân luồng đã không biến mất, các chip lõi tứ Nehalem mới của Intel có khả năng siêu phân luồng. Về việc nó có được khuyến nghị hay không, "nó phụ thuộc" như mọi khi, mỗi tình huống có thể khác nhau.

HT không chắc là nguyên nhân cốt lõi của bất kỳ vấn đề hiệu suất nào, nhưng không có thêm chi tiết, thật khó để nói đó là gì. Thực hiện một số phiên perfmon, với tốc độ mẫu khá dài, cứ sau 30 - 60 giây và nhận cpu, chiều dài hàng đợi đĩa trên dữ liệu và đĩa nhật ký, tuổi thọ trang là thước đo tốt cho việc bạn có đủ bộ nhớ hay không. Nếu bạn bao gồm hơn 80% CPU hoặc hàng đợi đĩa của bạn có ba chữ số, bạn đã tìm thấy vấn đề của mình.

SQL Server 2000 trên HP DL360 G3:

Tôi đã chạy một báo cáo sáu lần và tôi đã bỏ chạy ban đầu và ghi lại năm lần cuối cùng. Sau đó tôi khởi động lại cơ sở dữ liệu một lần nữa và bật lại Hyperthreading. Tôi đã chạy báo cáo sáu lần nữa, giữ lại dữ liệu từ năm lần chạy trước.

Quan sát:

• Tắt Hyperthreading không tốn gấp 2 lần sử dụng CPU rõ ràng, chỉ khoảng 1,5 lần.
• Tắt Hyperthreading làm cho một báo cáo chạy dài ngẫu nhiên chạy nhanh hơn 5,2% (trung bình).

Lặp đi lặp lại của báo cáo:

Với siêu phân luồng: 20,95%, 21,1%, 21,9%, 20,8%, 20,5%
Thời gian chạy trong ms: 20282, 21141, 20188, 22297, 25282. Trung bình 21838

Không có siêu phân luồng: 29,4%, 28,2%, 29,1%, 28,2%, 27,1%
Thời gian chạy trong ms: 20125, 20156, 19937, 21656, 21656. Trung bình 20706