Sẽ vô hiệu hóa siêu phân luồng cải thiện hiệu suất khi cài đặt SQL Server của chúng tôi


28

Liên quan đến: Sự khôn ngoan hiện tại trên SQL Server và Hyperthreading

Gần đây, chúng tôi đã nâng cấp máy chủ cơ sở dữ liệu Windows 2008 R2 từ X5470 lên X5560 . Lý thuyết là cả hai CPU đều có hiệu năng rất giống nhau, nếu có gì thì X5560 nhanh hơn một chút.

Tuy nhiên, hiệu suất SQL Server 2008 R2 đã khá tệ trong ngày hôm qua và việc sử dụng CPU khá cao.

Tuổi thọ của trang là rất lớn, chúng tôi đang nhận được gần như 100% bộ nhớ cache cho các trang, vì vậy bộ nhớ không phải là vấn đề.

Khi tôi chạy:

SELECT * FROM sys.dm_os_wait_stats 
order by signal_wait_time_ms desc

Tôi đã nhận:

Wait_type Wait_t Nhiệm_count Wait_time_ms max_wait_time_ms signal_wait_time_ms
-------------------------------------------------- ---------- -------------------- -------------------- -------------------- --------------------
XE_TIMER_EVENT 115166 2799125790 30165 2799125065
REQUEST_FOR_DEADLOCK_SEARCH 559393 2799053973 5180 2799053973
SOS_SCHEDULER_YIELD 152289883 189948844 960 189756877
CXPACKET 234638389 2383701040 141334 118796827
SLEEP_TASK 170743505 1525669557 1406 76485386
LATCH_EX 97301008 810738519 1107 55093884
LOGMGR_QUEUE 16525384 2798527632 20751319 4083713
VIẾT 16850119 18328365 1193 2367880
PAGELATCH_EX 13254618 8524515 11263 1670113
ASYNC_NETWORK_IO 23954146 6981220 7110 1475699

(10 hàng bị ảnh hưởng)

Tôi cũng đã chạy

-- Isolate top waits for server instance since last restart or statistics clear
WITH Waits AS (
   SELECT 
        wait_type, 
        wait_time_ms / 1000. AS [wait_time_s],
        100. * wait_time_ms / SUM(wait_time_ms) OVER() AS [pct],
        ROW_NUMBER() OVER(ORDER BY wait_time_ms DESC) AS [rn]
FROM sys.dm_os_wait_stats
WHERE wait_type NOT IN ('CLR_SEMAPHORE','LAZYWRITER_SLEEP','RESOURCE_QUEUE',
    'SLEEP_TASK','SLEEP_SYSTEMTASK','SQLTRACE_BUFFER_FLUSH','WAITFOR','LOGMGR_QUEUE',
    'CHECKPOINT_QUEUE','REQUEST_FOR_DEADLOCK_SEARCH','XE_TIMER_EVENT','BROKER_TO_FLUSH',
    'BROKER_TASK_STOP','CLR_MANUAL_EVENT','CLR_AUTO_EVENT','DISPATCHER_QUEUE_SEMAPHORE',
    'FT_IFTS_SCHEDULER_IDLE_WAIT','XE_DISPATCHER_WAIT', 'XE_DISPATCHER_JOIN'))

SELECT W1.wait_type, 
    CAST(W1.wait_time_s AS DECIMAL(12, 2)) AS wait_time_s,
    CAST(W1.pct AS DECIMAL(12, 2)) AS pct,
    CAST(SUM(W2.pct) AS DECIMAL(12, 2)) AS running_pct
FROM Waits AS W1
INNER JOIN Waits AS W2 ON W2.rn <= W1.rn
GROUP BY W1.rn, W1.wait_type, W1.wait_time_s, W1.pct
HAVING SUM(W2.pct) - W1.pct < 95; -- percentage threshold

Và có

Wait_type Wait_time_s pct đang chạy_pct
CXPACKET 554821.66 65.82 65.82
LATCH_EX 184123.16 21.84 87.66
SOS_SCHEDULER_YIELD 37541,17 4,45 92.11
PAGEIOLATCH_SH 19018.53 2.26 94.37
FT_IFTSHC_MUTEX 14306.05 1.70 96,07

Điều đó cho thấy số lượng lớn các truy vấn đồng bộ hóa thời gian liên quan đến tính song song (CXPACKET cao). Ngoài ra, nhiều giai đoạn trong số các truy vấn vấn đề này đang được thực thi trên nhiều lõi (chúng tôi không có gợi ý MAXDOP ở bất kỳ đâu trong mã của chúng tôi)

Máy chủ đã không được tải trong hơn một ngày. Chúng tôi đang gặp phải một lượng lớn phương sai với thực thi truy vấn, thông thường nhiều truy vấn dường như chậm hơn so với trên máy chủ DB trước đây của chúng tôi và CPU thực sự rất cao.

Sẽ vô hiệu hóa Hyperthreading giúp giảm mức sử dụng CPU của chúng tôi và tăng thông lượng?



Hãy nhớ rằng CXPACKET không có nghĩa là có rất nhiều thời gian chờ đợi các quy trình được hợp nhất với nhau. CXPACKET có nghĩa là luồng đang chờ một luồng khác hoàn tất xử lý. Bạn cần xem xét một truy vấn cụ thể có một luồng trong chờ đợi CXPACKET và xem các luồng khác đang chờ gì ngoài CXPACKET. Nó thường là IO hoặc mạng. Trong đầu ra ở trên, bạn đang chờ chốt và bị bỏ rơi. Một số truy vấn cần được điều chỉnh hoặc bạn cần xem lý do tại sao chốt được thực hiện.
mrdenny

Trong trường hợp của chúng tôi, CXPACKET rất cao vì các luồng khác chỉ đọc quá mức từ bộ đệm (20 triệu lượt đọc logic cho mỗi truy vấn). Trường hợp của chúng tôi, một lần nữa, là một chất chống semijoin tồi với bảng được phân vùng chỉ có 700K hàng.
ozamora

@mrdenny, yeah thời gian chờ chốt cao liên quan đến chúng tôi đang điều tra nó vào lúc này.
Sam Saffron

Câu trả lời:


10

Tôi vẫn cảm thấy rằng kiểm tra khối lượng công việc cụ thể của bạn , theo câu trả lời ban đầu, là cách duy nhất để chắc chắn. Đó không phải là một câu trả lời lý tưởng khi bạn đang cố gắng điều chỉnh một hệ thống sản xuất (vì vậy tôi hỏi liệu có thể có được một thử nghiệm giống hệt nhau trong các hệ thống mà cả hiệu suất và tính sẵn sàng thực sự quan trọng không) nhưng đó là điều duy nhất tôi thực sự thoải mái với.

Chúng ta có thể nói về lý thuyết về việc Hyperthreading có nên làm tổn thương hay cải thiện mọi thứ nói chung hay không (tôi thấy nó có khả năng bị tổn thương hơn là giúp đỡ trên các máy chủ vì vậy để triển khai "chung chung" tôi có thể vô hiệu hóa nó), nhưng có chỉ có một cách để biết chắc chắn liệu nó có tạo ra sự khác biệt trong trường hợp cụ thể của bạn hay không, và đó là thử và xem.


3
Lưu ý tôi đã không downvote, chúng tôi cần tất cả sự giúp đỡ chúng tôi có thể nhận được, tuy nhiên chúng tôi muốn tránh bị đâm trong bóng tối trên một hệ thống sản xuất. Tôi muốn đảm bảo rằng chúng tôi đã thu thập đủ chẩn đoán trước khi thực hiện cuộc gọi khi chơi với cài đặt này.
Sam Saffron

3
Tôi chắc chắn rằng bạn muốn tránh 'chơi' với một hệ thống sản xuất, trong một thế giới lý tưởng, tất cả chúng ta đều có môi trường thử nghiệm giống hệt như sản xuất vì lý do đó. Tôi đồng ý với việc không muốn thay đổi sản xuất trên đầu cơ. Tuy nhiên, tôi đứng trước câu trả lời của mình: Kiểm tra khối lượng công việc cụ thể là một phần quan trọng của bất kỳ triển khai nào và bất kỳ ai nói với bạn sự khác biệt là một charlatan. Đối với tôi, tất cả các dấu hiệu cho thấy siêu phân luồng là một vấn đề ở đây nhưng chúng ta có thể nói về mọi thứ cả ngày lẫn đêm và vẫn chỉ có một cách để biết chắc chắn.
Rob Moir

5
Upvote ở đây - Tôi đồng ý với câu trả lời. Câu trả lời chung là: Tắt Hyperthreading. Câu trả lời cụ thể hơn là: Nó phụ thuộc vào chi tiết cụ thể và PHẢI ĐƯỢC KIỂM TRA.
TomTom

1
Thật kỳ lạ, tôi nghĩ rằng đây là câu trả lời tốt nhất để chấp nhận, việc lén lút với các cài đặt maxdop có thể dẫn đến nhiều rắc rối, nehalem cpus nhanh hơn nhiều so với các xe dựa trên lõi ngay cả ở tốc độ xung nhịp chậm, tôi thấy các đối số được lưu trong bộ nhớ cache l2 một chút của một cá trích đỏ khiến bộ đệm l3 lớn hơn nhiều. Là một phụ lục, hãy xem: blog.stackoverflow.com/2010/10/database-upTHER , nếu bất kỳ ai đang nhìn thấy hơn 20% phần trăm lượt truy cập / tăng ... có lẽ không phải do HT.
Sam Saffron

Tôi đã có trải nghiệm ngược lại với @TomTom và @Robert. Tôi thấy rằng HT trên thường tốt hơn 10-15% so với tắt. Sự kiện tắt nó cải thiện hiệu suất thực sự hiếm.
Brian Knoblauch

12

Tôi đồng ý rằng

  • tại tốt nhất đề nghị được "thử HyperThreading trên khối lượng công việc của bạn và xem những gì sẽ xảy ra". Chúng tôi đang làm điều này ngay bây giờ khi tôi gõ, và .. nó không tốt!
  • có lẽ bạn nên luôn luôn bắt đầu với HyperThreading bị tắt, vì đó là cách an toàn nhất

Có vẻ như chúng ta nên điều chỉnh hai điều:

  1. MAXDOP (Độ song song tối đa). Tất cả mọi thứ tôi đọc chỉ ra rằng việc không bị ràng buộc này có lẽ là một ý tưởng tồi và tài liệu của Microsoft nói:

    Đặt tùy chọn này [MAXDOP] thành giá trị lớn hơn [8] thường gây ra sự tiêu thụ tài nguyên không mong muốn và suy giảm hiệu suất.

    bất cứ điều gì cao hơn 8thường không được khuyến nghị .. vì vậy tôi đặt nó 4bây giờ. Đó là con số không (không giới hạn) ban đầu.

  2. Ngưỡng chi phí cho song song. Rõ ràng mặc định 5ở đây được coi là một mặc định khá thấp theo một số bài đăng MVP SQL mà tôi đã tìm thấy - chúng ta có thể điều chỉnh nó để giảm mức độ song song của trình lập lịch.

Nhưng thành thật mà nói những cảm giác như cách giải quyết; Tôi nghĩ rằng giải pháp thực sự cho khối lượng công việc của chúng tôi (chỉ số toàn văn nặng) là vô hiệu hóa HT.


4
MAXDOP cũng gây ra sự cố với HT vì nó có thể cố gắng thực thi hai luồng trên cùng một CPU nếu bạn nói, 8 lõi và 16 luồng và maxdop của bạn được đặt thành 10. Nói chung, 1 MAXDOP cho mỗi bộ xử lý logic phải là tối đa. Và thực thi hai luồng trên cùng một CPU cho cùng một quy trình là vô nghĩa.
Mark Henderson

2
@Fudeeker chỉ xảy ra nếu bạn không có hệ điều hành nhận biết HyperThreading. Windows mới hơn 2000 nhận thức được điều đó.
Mircea Chirea

Điều đáng chú ý là các phần ghi đè maxdop này chỉ gây ra sự cố. mặc định là tốt cho chúng tôi
Sam Saffron

2
Phiên bản tiêu chuẩn của SQL Server đạt tối đa ở mức tối đa 4 chiều khi không bị chặn. Cần doanh nghiệp để đi cao hơn thế. Chúng tôi đã có một số khối lượng công việc tăng nhanh nhất với MAXDOP là 1 (hộp không HT, chạy nhiều AMD 8 lõi) ...
Brian Knoblauch

1
@Brian Knoblauch - Tôi biết điều này hơn một năm sau, nhưng tôi đã chạy qua "Phiên bản SQL Server tiêu chuẩn này đạt tối đa MAXDOP của 4 đường khi không bị chặn" bất kỳ cơ hội nào bạn có thể chỉ cho tôi về một số tài liệu. Chúng tôi hiện đang nói về việc sử dụng MAXDOP tại nơi làm việc nhưng không chắc chắn nên cài đặt cái gì. Điều này về cơ bản có nghĩa là 4 giống như không liên kết đúng?
Jeremy A. West

9

Anandtech nhận thấy rằng với tải đọc thuần túy, nó bị tổn thương một chút và với tải nặng ghi, đó là một chút chiến thắng. Tôi chưa thấy bất cứ điều gì khiến tôi nghĩ rằng nó sẽ khiến bạn bị đánh nặng hơn nhiều so với -5%, hoặc chiến thắng tốt hơn 15%. Lưu ý những gì với một nguyên tử, nó là một chiến thắng lớn, nhưng đó là một cpu rất kỳ quặc.

Tất cả những gì bạn thay đổi là cpu? Bạn đã chuyển từ bộ nhớ cache 12 MB và 4 luồng, vì vậy 3 MB bộ đệm cho mỗi luồng, đến 8 MB bộ đệm và 8 luồng, vì vậy 1 MB cho mỗi luồng. Bây giờ, đó là quá đơn giản, nhưng tôi cá rằng đó là thứ đang giết chết bạn, bạn đã từng chạy truy vấn trong bộ đệm và bây giờ chạy chúng từ RAM vì chúng cần nhiều hơn 1MB nhưng ít hơn 3 MB. Tắt HT có thể sẽ giúp ích, nhưng tôi sẽ quay lại CPU cũ. Tắt HT và bạn nhận được 2 MB cho mỗi luồng, nhưng nếu khối lượng công việc của bạn giảm nhiều như vậy, điều đó sẽ không giúp ích gì. Nó cũng có thể là cpu bộ nhớ cache 12 MB cũ nhanh hơn cho khối lượng công việc của bạn.

Tôi sẽ thử tắt HT và xem đó có phải là một cải tiến hay không, nhưng tôi nghi ngờ rằng bộ đệm là vua cho tải công việc của bạn và bạn có thể cần quay lại chip 12 MB.


3
Bộ đệm L2 cho mỗi lần quan sát lõi là một sự đơn giản hóa lớn , vì CPU là một thế hệ đầy đủ phía trước (lớp Nehalem / Core i7 so với Core 2 Quad).
Jeff Atwood

@Jess, @Ronald và Nehalem có ít bộ đệm L2. Phần lớn là L3 được chia sẻ trên các lõi.
Mircea Chirea

7

Hyperthreading, tốt nhất, chỉ là một cách trừu tượng hóa nhiệm vụ chuyển khỏi hệ điều hành và đặt nó vào trạng thái chết, với quyền truy cập trực tiếp vào bộ đệm L1 và L2, giúp chuyển đổi tác vụ nhanh hơn.

Thử nghiệm với VMWare đã chỉ ra rằng việc vô hiệu hóa HT không có sự khác biệt rõ rệt trong tải tiêu chuẩn và tăng 5% khi tải nặng, do thực tế là ESXi đủ thông minh để biết sự khác biệt giữa luồng "thật" và luồng "giả" (có một nhiều hơn để nó hơn thế, nhưng đó là về laymens). SQL Server 2005 không hoàn toàn thông minh, nhưng nó kết hợp với một hệ điều hành cập nhật nên sẽ có ít lợi thế để vô hiệu hóa HT.

Tất cả những gì đã nói, tôi đồng ý với Ronald rằng rất có thể đó sẽ là bộ đệm L2 của bạn. Giảm 33% kích thước bộ đệm là đáng kể và khi chúng tôi chỉ định Máy chủ SQL của mình, chúng tôi luôn tìm bộ đệm trên tốc độ xung nhịp thô mỗi lần.


Bạn có thể đặt mối quan hệ bên ngoài để 4 lõi bên phải bị SQL bỏ qua không?
Sam Saffron

3
Nói chung, bạn sẽ đặt mối quan hệ với các luồng CPU khác, nhưng miễn là MAXDOP được đặt chính xác, tôi thấy không có lý do gì để thiết lập mối quan hệ cả. Với HT mặc dù luồng đầu tiên bị tấn công trên CPU trở thành luồng "chính" và luồng thứ 2 là luồng "HT". Mặc dù không có chủ đề "chính" và "ht" thực sự, bởi vì đó là bất kỳ chủ đề nào có trước, và sau đó khi chúng chuyển đổi nhiệm vụ, thứ tự được đảo ngược.
Mark Henderson

Các CPU dựa trên Nehalem có bộ đệm RẤT, RẤT LITTLE L2, hầu hết được chia sẻ L3.
Mircea Chirea

7

Dựa trên kinh nghiệm của tôi, HT đã khiến các hoạt động I / O mất vĩnh viễn các nút hoạt động của tôi trên Cụm Windows 2008 R2 (chạy SQL Server 2008 R2). Một sự thật thú vị là nó không được phản ánh trong các số liệu thống kê chờ đợi cũng như trong pssdiag mà tôi đã chạy để hỗ trợ Microsoft.

Cách tôi nhận thấy I / O thấp chỉ bằng cách xem các bộ đếm hệ điều hành cho đĩa vật lý. Như Sam đã chỉ ra, tôi đã viết về nó ở đâyở đây

Nếu bạn KHÔNG gặp phải sự cố I / O và bị ràng buộc CPU, tôi khuyên bạn nên bắt đầu theo cách này:

Xác định chính xác các quy trình và khối T-SQL đang gây ra việc sử dụng CPU nhiều nhất. Theo kinh nghiệm của chúng tôi, sau khi chúng tôi khắc phục sự cố với I / O (bằng cách tắt HT), chúng tôi đã xác định được mã đang hoạt động khủng khiếp trong năm 2008 R2 và hoạt động tốt vào năm 2005. Tôi đã viết về nó ở đây .

Trong khi chịu tải cao, hãy chạy sp_whoisactive của Adam Machanic. Bạn có thể tải nó từ đây . Chúng tôi đã trải qua việc sử dụng CPU rất cao do số lần đọc logic quá nhiều (20 triệu cho mỗi truy vấn) do một kế hoạch thực sự tồi tệ. Các quy trình của chúng tôi đã thực hiện các phép nối chống bán với các bảng được phân vùng.

Đề xuất tiếp theo của tôi là chạy profiler để xác định một bộ mã T-SQL có cả số lần đọc logic và I / O cao của CPU.

Với các bước trên, chúng tôi đã có thể điều chỉnh các quy trình vi phạm và đi từ mức sử dụng CPU được duy trì 85% đến gần như không.

Chúc may mắn và xin vui lòng gửi cho tôi một dòng nếu bạn tìm thấy một sửa chữa như tôi muốn thêm trường hợp vào blog của tôi.

Cảm ơn

Giải Oscar


1
+1 cho trình tạo hồ sơ, đã cứu tôi nhiều lần khi một điểm rắc rối đã được xác định
Mark Henderson

+1 cảm ơn tất cả các đề xuất của bạn, điều chỉnh SQL của chúng tôi ở mức hợp lý là một cơn ác mộng hoàn toàn, chúng tôi phụ thuộc khá nhiều vào toàn văn cho các giao dịch của chúng tôi với các thẻ, chúng tôi thường tìm kiếm một danh sách các mục trong các thẻ cụ thể để chúng tôi lấy toàn bộ đặt và lọc nó xuống. Ví dụ: nhận danh sách các câu hỏi có thẻ [x] và [y] được sắp xếp theo ngày liên quan đến việc lấy một lượng lớn dữ liệu từ toàn văn bản và sau đó tham gia lớn.
Sam Saffron

Hiểu. Lấy một mẫu và chạy nó với số liệu thống kê IO ON và xem liệu bạn có thể xác định chính xác bất kỳ bảng nào có số lần đọc hợp lý nhất không. Một lần nữa, chúng tôi đã làm rất tốt trong năm 2005 và thực sự tồi tệ trong năm 2008 R2. Nếu bạn chỉ thấy mức độ sử dụng CPU cao và có thời gian chờ CXPACKET cao, hãy thử trước bằng cách tăng Ngưỡng chi phí cho song song lên 10, 15 hoặc thậm chí 20.
ozamora

Nếu không có gì khác giúp, ngoại tuyến DB, tắt HT và đi từ đó. Chúc may mắn
ozamora

sp_whoisactive là một công cụ khá tuyệt vời, yêu thích cách truy vấn có thể nhấp
Sam Saffron

2

Cho dù HT là tốt hay xấu là khó để xác định.

Nó thực sự phụ thuộc vào mô hình tải máy chủ dựa trên kinh nghiệm và đọc. Đó là, khi nó ảnh hưởng đến hiệu suất, nó rất tệ : nếu không bạn sẽ không chú ý đến nó.

Lý thuyết tôi đọc là các luồng chia sẻ bộ đệm có nghĩa là trong các điều kiện bất lợi, mỗi luồng có thể ghi đè lên bộ đệm của luồng khác. Nếu bạn không có nhiều sự song song hoặc tải của bạn có nhiều truy vấn ngắn, thì nó có thể không ảnh hưởng đến bạn.

Tôi đã thử với MAXDOP và mối quan hệ bộ xử lý (trở lại vai trò DBA thực sự cuối cùng của tôi trên SQL Server 2000) nhưng không bao giờ có thể tìm thấy kết luận nào: nhưng chỉ cho cửa hàng của tôi tại thời điểm đó.

Để kiểm tra nhanh, bạn có thể đặt ái lực của bộ xử lý chỉ sử dụng các lõi vật lý (số thấp hơn) và xem điều gì sẽ xảy ra.

Tuy nhiên, nhiều nhất bạn mất một nửa số lõi của mình. Ngày nay, điều đó có thể không quan trọng so với những gì tôi đã chơi với một vài năm trước đây khi nó là 2 vs 4 hoặc 4 so với 8. Bây giờ là 8 so với 16 hoặc 16 so với 32.

Chỉnh sửa: Một bài kiểm tra của Slava Oks


các lõi 0-3 vật lý và 4-7 logic? nó vận hành như vậy sao? Chúng tôi không thể nói, và tôi không thể tìm ra bất kỳ công cụ nào để cho tôi biết ..
Jeff Atwood

2
@Jeff Atwood: Tôi sẽ tìm thấy nhiều hơn sau. Tôi đã đọc nó ở đâu đó .... Bây giờ: support.microsoft.com/kb/322385
gbn

Bài viết KB đó tổng hợp khá nhiều.
pauseka

Mặc dù bài viết KB đó có chứa một số thông tin hữu ích, nhưng dường như nó không trả lời trực tiếp câu hỏi của Jeff về cách chính xác các bộ xử lý logic được ánh xạ tới các bộ xử lý vật lý. Bộ não của tôi chiên khoảng một nửa chiều qua, nhưng hy vọng bài viết INTEL này sẽ cung cấp cho bạn những gì bạn cần phải tìm ra các bản đồ: software.intel.com/en-us/articles/... cũng thấy software.intel.com/en-us/ blog / 2009/12/21 / Hoài với các liên kết liên quan.
BradC

@Jeff Atwood, @BradC: Chúa ơi, khó tìm. Xem điều này: nó dựa trên các khuyến nghị của Intel. SQL Server sẽ sử dụng Windows liệt kê cơ bản download.microsoft.com/doad/5/7/7/ .
gbn

2

Thật không may, tôi không nghĩ rằng bạn sẽ nhận được bất kỳ câu trả lời dứt khoát nào hơn là "thử tắt siêu âm và xem nếu điều đó có ích".

Mặc dù câu trả lời hữu ích từ Jonathan trong chủ đề ban đầu của tôi (mà bạn đã liên kết trong câu hỏi của bạn), tôi không bao giờ có thể nhận được bất kỳ bằng chứng chắc chắn nào về tác động của HT trên các máy chủ cụ thể mà tôi đang điều tra. Trong trường hợp của tôi, các máy chủ đã được lên lịch để thay thế, vì vậy chúng tôi chỉ cần để những sự thay thế đó "giải quyết vấn đề" để nói.

Lời khuyên của tôi:

Hãy thử cài đặt Cấp độ song song MAX cấp độ máy chủ là 1 . Tính song song trên SQL là hữu ích nhất cho các truy vấn lớn hơn, chạy lâu hơn và tải của bạn (tôi giả sử) bao gồm một số lượng lớn các truy vấn nhỏ hơn. Điều này sẽ loại bỏ hoàn toàn sự chờ đợi CXPACKET. Điều này có thể làm cho một số truy vấn riêng lẻ chạy lâu hơn một chút, nhưng sẽ cho phép nhiều "thông lượng" hơn trong tổng số truy vấn trên máy chủ.

Tôi đã có kết quả tốt khi làm điều này trên các máy chủ OLTP. Các loại máy chủ khác (máy chủ báo cáo, máy chủ xử lý, kho dữ liệu) chắc chắn cần bộ MAXDOP cao hơn.

Và để rõ ràng, cài đặt này vẫn sẽ cho phép SQL sử dụng nhiều luồng cho mỗi bảng riêng lẻ trong một THAM GIA, do đó bạn không thực sự loại bỏ hoàn toàn song song.

Ít nhất là đáng để thử, vì thay đổi cài đặt này có hiệu lực ngay lập tức và thậm chí không yêu cầu bạn khởi động lại dịch vụ SQL: http://msdn.microsoft.com/en-us/l Library / ms181007.aspx
Điều này có nghĩa là bạn có thể chuyển đổi nó trở lại ngay lập tức nếu mọi thứ bắt đầu xuống địa ngục.

Tắt siêu phân luồng trong BIOS sẽ yêu cầu khởi động lại máy chủ đầy đủ, do đó sẽ rủi ro hơn một chút.


0

Đối với hồ sơ, chúng tôi cũng có hiệu suất bất ngờ sau khi nâng cấp máy chủ. Hóa ra là do vấn đề với việc tiết kiệm năng lượng của BIOS và CPU. Cài đặt mặc định trên máy chủ (HP) là bỏ qua kiểm soát hệ điều hành về tốc độ CPU và sử dụng thuật toán riêng của nó. Thay đổi điều này thành kiểm soát hệ điều hành và cập nhật BIOS, dẫn đến những cải tiến đáng kể. Có một số lưu ý phát hành (không thể tìm thấy chúng bây giờ) rằng có một lỗi BIOS đang khóa CPU ở trạng thái hiệu suất thấp nhất.

https://serverfault.com/a/196329/6390

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.