Cài đặt MAXDOP cho SQL Server 2014


8

Tôi biết câu hỏi này đã được hỏi nhiều lần và cũng có câu trả lời cho nó, nhưng tôi vẫn cần thêm một chút hướng dẫn về chủ đề này.

Dưới đây là chi tiết về CPU của tôi từ SSMS:

CPU

Dưới đây là tab CPU từ trình quản lý tác vụ của Máy chủ DB:

Thẻ CPU

Tôi đã giữ cài đặt MAXDOPở mức 2 bằng cách làm theo công thức dưới đây:

declare @hyperthreadingRatio bit
declare @logicalCPUs int
declare @HTEnabled int
declare @physicalCPU int
declare @SOCKET int
declare @logicalCPUPerNuma int
declare @NoOfNUMA int
declare @MaxDOP int

select @logicalCPUs = cpu_count -- [Logical CPU Count]
    ,@hyperthreadingRatio = hyperthread_ratio --  [Hyperthread Ratio]
    ,@physicalCPU = cpu_count / hyperthread_ratio -- [Physical CPU Count]
    ,@HTEnabled = case 
        when cpu_count > hyperthread_ratio
            then 1
        else 0
        end -- HTEnabled
from sys.dm_os_sys_info
option (recompile);

select @logicalCPUPerNuma = COUNT(parent_node_id) -- [NumberOfLogicalProcessorsPerNuma]
from sys.dm_os_schedulers
where [status] = 'VISIBLE ONLINE'
    and parent_node_id < 64
group by parent_node_id
option (recompile);

select @NoOfNUMA = count(distinct parent_node_id)
from sys.dm_os_schedulers -- find NO OF NUMA Nodes 
where [status] = 'VISIBLE ONLINE'
    and parent_node_id < 64

IF @NoofNUMA > 1 AND @HTEnabled = 0
    SET @MaxDOP= @logicalCPUPerNuma 
ELSE IF  @NoofNUMA > 1 AND @HTEnabled = 1
    SET @MaxDOP=round( @NoofNUMA  / @physicalCPU *1.0,0)
ELSE IF @HTEnabled = 0
    SET @MaxDOP=@logicalCPUs
ELSE IF @HTEnabled = 1
    SET @MaxDOP=@physicalCPU

IF @MaxDOP > 10
    SET @MaxDOP=10
IF @MaxDOP = 0
    SET @MaxDOP=1

PRINT 'logicalCPUs : '         + CONVERT(VARCHAR, @logicalCPUs)
PRINT 'hyperthreadingRatio : ' + CONVERT(VARCHAR, @hyperthreadingRatio) 
PRINT 'physicalCPU : '         + CONVERT(VARCHAR, @physicalCPU) 
PRINT 'HTEnabled : '           + CONVERT(VARCHAR, @HTEnabled)
PRINT 'logicalCPUPerNuma : '   + CONVERT(VARCHAR, @logicalCPUPerNuma) 
PRINT 'NoOfNUMA : '            + CONVERT(VARCHAR, @NoOfNUMA)
PRINT '---------------------------'
Print 'MAXDOP setting should be : ' + CONVERT(VARCHAR, @MaxDOP)

Tôi vẫn đang thấy thời gian chờ đợi cao liên quan đến CXPACKET. Tôi đang sử dụng truy vấn dưới đây để có được điều đó:

WITH [Waits] AS
(SELECT
[wait_type],
[wait_time_ms] / 1000.0 AS [WaitS],
([wait_time_ms] - [signal_wait_time_ms]) / 1000.0 AS [ResourceS],
[signal_wait_time_ms] / 1000.0 AS [SignalS],
[waiting_tasks_count] AS [WaitCount],
100.0 * [wait_time_ms] / SUM ([wait_time_ms]) OVER() AS [Percentage],
ROW_NUMBER() OVER(ORDER BY [wait_time_ms] DESC) AS [RowNum]
FROM sys.dm_os_wait_stats
WHERE [wait_type] NOT IN (
N'BROKER_EVENTHANDLER', N'BROKER_RECEIVE_WAITFOR',
N'BROKER_TASK_STOP', N'BROKER_TO_FLUSH',
N'BROKER_TRANSMITTER', N'CHECKPOINT_QUEUE',
N'CHKPT', N'CLR_AUTO_EVENT',
N'CLR_MANUAL_EVENT', N'CLR_SEMAPHORE',
N'DBMIRROR_DBM_EVENT', N'DBMIRROR_EVENTS_QUEUE',
N'DBMIRROR_WORKER_QUEUE', N'DBMIRRORING_CMD',
N'DIRTY_PAGE_POLL', N'DISPATCHER_QUEUE_SEMAPHORE',
N'EXECSYNC', N'FSAGENT',
N'FT_IFTS_SCHEDULER_IDLE_WAIT', N'FT_IFTSHC_MUTEX',
N'HADR_CLUSAPI_CALL', N'HADR_FILESTREAM_IOMGR_IOCOMPLETION',
N'HADR_LOGCAPTURE_WAIT', N'HADR_NOTIFICATION_DEQUEUE',
N'HADR_TIMER_TASK', N'HADR_WORK_QUEUE',
N'KSOURCE_WAKEUP', N'LAZYWRITER_SLEEP',
N'LOGMGR_QUEUE', N'ONDEMAND_TASK_QUEUE',
N'PWAIT_ALL_COMPONENTS_INITIALIZED',
N'QDS_PERSIST_TASK_MAIN_LOOP_SLEEP',
N'QDS_CLEANUP_STALE_QUERIES_TASK_MAIN_LOOP_SLEEP',
N'REQUEST_FOR_DEADLOCK_SEARCH', N'RESOURCE_QUEUE',
N'SERVER_IDLE_CHECK', N'SLEEP_BPOOL_FLUSH',
N'SLEEP_DBSTARTUP', N'SLEEP_DCOMSTARTUP',
N'SLEEP_MASTERDBREADY', N'SLEEP_MASTERMDREADY',
N'SLEEP_MASTERUPGRADED', N'SLEEP_MSDBSTARTUP',
N'SLEEP_SYSTEMTASK', N'SLEEP_TASK',
N'SLEEP_TEMPDBSTARTUP', N'SNI_HTTP_ACCEPT',
N'SP_SERVER_DIAGNOSTICS_SLEEP', N'SQLTRACE_BUFFER_FLUSH',
N'SQLTRACE_INCREMENTAL_FLUSH_SLEEP',
N'SQLTRACE_WAIT_ENTRIES', N'WAIT_FOR_RESULTS',
N'WAITFOR', N'WAITFOR_TASKSHUTDOWN',
N'WAIT_XTP_HOST_WAIT', N'WAIT_XTP_OFFLINE_CKPT_NEW_LOG',
N'WAIT_XTP_CKPT_CLOSE', N'XE_DISPATCHER_JOIN',
N'XE_DISPATCHER_WAIT', N'XE_TIMER_EVENT')
AND [waiting_tasks_count] > 0
)
SELECT
MAX ([W1].[wait_type]) AS [WaitType],
CAST (MAX ([W1].[WaitS]) AS DECIMAL (16,2)) AS [Wait_S],
CAST (MAX ([W1].[ResourceS]) AS DECIMAL (16,2)) AS [Resource_S],
CAST (MAX ([W1].[SignalS]) AS DECIMAL (16,2)) AS [Signal_S],
MAX ([W1].[WaitCount]) AS [WaitCount],
CAST (MAX ([W1].[Percentage]) AS DECIMAL (5,2)) AS [Percentage],
CAST ((MAX ([W1].[WaitS]) / MAX ([W1].[WaitCount])) AS DECIMAL (16,4)) AS [AvgWait_S],
CAST ((MAX ([W1].[ResourceS]) / MAX ([W1].[WaitCount])) AS DECIMAL (16,4)) AS [AvgRes_S],
CAST ((MAX ([W1].[SignalS]) / MAX ([W1].[WaitCount])) AS DECIMAL (16,4)) AS [AvgSig_S]
FROM [Waits] AS [W1]
INNER JOIN [Waits] AS [W2]
ON [W2].[RowNum] <= [W1].[RowNum]
GROUP BY [W1].[RowNum]
HAVING SUM ([W2].[Percentage]) - MAX ([W1].[Percentage]) < 95; -- percentage threshold
GO

Hiện tại CXPACKETchờ đợi ở mức 63% cho máy chủ của tôi:

Thống kê chờ

Tôi đã đề cập đến nhiều bài viết về khuyến nghị từ các chuyên gia và cũng đã xem xét các MAXDOPđề xuất của Microsoft ; tuy nhiên, tôi không thực sự chắc chắn cái gì sẽ là giá trị tối ưu cho cái này.

Tôi đã tìm thấy một câu hỏi về cùng một chủ đề ở đây, tuy nhiên nếu tôi đi với đề xuất đó của Kin thì MAXDOPnên là 4. Trong cùng một câu hỏi, nếu chúng ta đi với Max Vernon, thì nó phải là 3.

Vui lòng cung cấp đề nghị có giá trị của bạn.

Phiên bản: Microsoft SQL Server 2014 (SP3) (KB4022619) - 12.0.6024.0 (X64) ngày 7 tháng 9 năm 2018 01:37:51 Phiên bản doanh nghiệp: Cấp phép dựa trên lõi (64-bit) trên Windows NT 6.3 (Build 9600 :) (Hypervisor )

Ngưỡng chi phí cho tính song song được đặt ở 70. CTfP đã được đặt thành 70 sau khi thử nghiệm tương tự cho các giá trị từ mặc định đến 25 và 50 tương ứng. Khi nó được mặc định (5) và MAXDOPlà 0, thời gian chờ là gần 70% cho CXPACKET.

Tôi đã thực hiện sp_blitzfirsttrong 60 giây ở chế độ chuyên gia và bên dưới là đầu ra cho các kết quả và thống kê chờ:

sp_blitzfirst


Tôi đồng ý với nhận xét của @JaredKarney trong câu trả lời của anh ấy: Bạn đang cố gắng khắc phục / giải quyết vấn đề gì? Bạn đang gặp phải hiệu suất xấu? Tại sao bạn tin rằng chờ đợi CXPACKET cao là xấu? Bạn có thể vui lòng giải thích tại sao tình huống của bạn khác với tất cả các câu hỏi và câu trả lời khác liên quan đến vấn đề này?
John aka hot2use

@ hot2use Có, tôi đang gặp vấn đề về hiệu suất và đang cố gắng xem tất cả các khía cạnh có thể có thể làm giảm hiệu suất. Tôi không phải là chuyên gia về số liệu thống kê chờ đợi của CXPACKET và do đó muốn có một số hướng dẫn từ các chuyên gia.
Learning_DBAdmin

Câu trả lời:


13

Không có kinh nghiệm

Đây là lý do tại sao báo cáo thống kê chờ đó bốc mùi: Nó không cho bạn biết máy chủ đã hoạt động được bao lâu.

Tôi có thể thấy nó trong ảnh chụp màn hình thời gian CPU của bạn: 55 ngày!

Được rồi, chúng ta hãy làm một số phép toán.

môn Toán

Có 86.400 giây trong ngày.

SELECT (86400 * 55) seconds_in_55_days

Câu trả lời ở đó? 4,752,000

Bạn có tổng số 452,488giây của CXPACKET.

SELECT 4752000 / 452488 AS oh_yeah_that_axis

Cung cấp cho bạn ... 10 (gần hơn 9,5 nếu bạn làm toán thực tế ở đây).

Vì vậy, trong khi CXPACKET có thể là 62% chờ đợi của máy chủ của bạn, thì điều đó chỉ xảy ra khoảng 10% thời gian.

Để nó một mình

Bạn đã thực hiện các điều chỉnh phù hợp cho cài đặt, đã đến lúc thực hiện điều chỉnh truy vấn và chỉ mục thực tế nếu bạn muốn thay đổi số theo cách có ý nghĩa.

Những ý kiến ​​khác

CXPACKET có thể phát sinh từ song song lệch:

Trên các phiên bản mới hơn, nó có thể xuất hiện dưới dạng CXCONSUMER:

Không có công cụ giám sát của bên thứ ba, có thể bạn nên tự mình nắm bắt các số liệu thống kê chờ đợi:


10

Thống kê chờ chỉ là con số. Nếu máy chủ của bạn đang làm bất cứ điều gì thì có khả năng bạn sẽ có một số loại chờ đợi xuất hiện. Ngoài ra, theo định nghĩa, phải có một chờ đợi sẽ có tỷ lệ phần trăm cao nhất. Điều đó không có nghĩa gì nếu không có một số loại bình thường. Máy chủ của bạn đã hoạt động được 55 ngày nếu tôi đọc chính xác đầu ra của trình quản lý tác vụ. Điều đó có nghĩa là bạn chỉ có 452000 / (55 * 86400) = 0,095 giây chờ trong CXPACKETtổng số giây. Ngoài ra, vì bạn đang ở trên SQL Server 2014, sự CXPACKETchờ đợi của bạn bao gồm cả chờ đợi song song lành tính và chờ đợi có thể hành động. Xem Làm song song chờ hành động để biết thêm chi tiết. Tôi sẽ không đi đến một kết luận MAXDOPđược đặt không chính xác dựa trên những gì bạn đã trình bày ở đây.

Trước tiên tôi sẽ đo thông lượng. Có thực sự có một vấn đề ở đây? Chúng tôi không thể cho bạn biết làm thế nào vì điều đó phụ thuộc vào khối lượng công việc của bạn. Đối với hệ thống OLTP, bạn có thể đo các giao dịch mỗi giây. Đối với một ETL, bạn có thể đo các hàng được tải mỗi giây, v.v.

Nếu bạn có vấn đề và cần cải thiện hiệu năng hệ thống thì tôi sẽ kiểm tra CPU trong suốt thời gian bạn gặp sự cố đó. Nếu CPU quá cao thì có lẽ bạn cần điều chỉnh các truy vấn của mình, tăng tài nguyên máy chủ hoặc giảm tổng số truy vấn đang hoạt động. Nếu CPU quá thấp thì bạn có thể lại cần điều chỉnh các truy vấn của mình, tăng tổng số truy vấn đang hoạt động hoặc có thể có một số loại chờ chịu trách nhiệm.

Nếu bạn chọn xem xét các số liệu thống kê chờ, bạn chỉ nên xem chúng trong khoảng thời gian bạn gặp vấn đề về hiệu suất. Nhìn vào số liệu thống kê chờ đợi toàn cầu trong 55 ngày qua đơn giản là không thể thực hiện được trong hầu hết các trường hợp. Nó thêm tiếng ồn không cần thiết vào dữ liệu làm cho công việc của bạn khó khăn hơn.

Khi bạn đã hoàn thành một cuộc điều tra thích hợp, có thể việc thay đổi MAXDOPsẽ giúp bạn. Đối với một máy chủ có kích thước của bạn, tôi sẽ giữ nguyên MAXDOP1, 2, 4 hoặc 8. Chúng tôi không thể cho bạn biết cái nào sẽ tốt nhất cho khối lượng công việc của bạn. Bạn cần theo dõi thông lượng của mình trước và sau khi thay đổi MAXDOPđể đưa ra kết luận.


0
  1. Maxdop 'bắt đầu' của bạn phải là 4; số lõi nhỏ nhất trên mỗi nút numa lên đến 8. Công thức của bạn không chính xác.

  2. Tỷ lệ cao chờ đợi cho một loại cụ thể có nghĩa là không có gì. Mọi thứ trong SQL chờ đợi, vì vậy một cái gì đó luôn luôn là cao nhất. Điều duy nhất mà cxpacket cao chờ đợi có nghĩa là bạn có tỷ lệ song song cao đang diễn ra. CPU nhìn chung không cao (ít nhất là cho ảnh chụp nhanh được cung cấp), vì vậy có lẽ không phải là vấn đề.

  3. Trước khi cố gắng giải quyết vấn đề, hãy xác định vấn đề. Vấn đề gì bạn đang cố gắng giải quyết? Trong trường hợp này, có vẻ như bạn đã xác định vấn đề là tỷ lệ phần trăm cao của cxpquet chờ đợi, nhưng bản thân nó không phải là vấn đề.


NUMA ảo có thể dễ dàng có 2 lõi cho mỗi nút numa. Tại sao bạn khẳng định 4 là số lõi nhỏ nhất trên mỗi nút numa? Bạn có thể giải thích những gì bạn có ý nghĩa?
Max Vernon

-2

Tôi nghĩ rằng câu hỏi thích hợp nhất là ... bạn có thực sự gặp phải bất kỳ vấn đề nào về hiệu suất không? Nếu câu trả lời là không, thì tại sao bạn lại tìm kiếm một vấn đề khi không có vấn đề?

Giống như các câu trả lời khác đã nói, mọi thứ đều chờ đợi và tất cả các chờ đợi CX chỉ ra là nếu bạn có các truy vấn diễn ra song song, một điều tôi sẽ đề cập là có thể bạn nên xem ngưỡng chi phí của bạn đối với tính song song được đặt ở NẾU bạn đang gặp vấn đề với các truy vấn đang diễn ra song song tức là các truy vấn nhỏ không thực hiện nhiều công việc song song và điều đó có thể làm cho chúng chạy kém hơn, không tốt hơn và các truy vấn lớn sẽ diễn ra song song vì tất cả các truy vấn nhỏ hơn đang chạy nghèo nàn

Nếu không, bạn không gặp vấn đề gì khi ngừng cố gắng tạo một cái.


Xin vui lòng đọc câu hỏi hoàn toàn, ngưỡng chi phí cho song song được cung cấp.
Learning_DBAdmin
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.