관련 : SQL Server 및 하이퍼 스레딩에 대한 현재의 지혜
최근에 Windows 2008 R2 데이터베이스 서버를 X5470 에서 X5560으로 업그레이드했습니다 . X5560이 조금 더 빠르면 두 CPU의 성능이 매우 비슷하다는 이론이 있습니다.
그러나 SQL Server 2008 R2 성능은 지난 하루 동안 상당히 나빴으며 CPU 사용량은 꽤 높습니다.
페이지 예상 수명이 엄청 나서 페이지에 대해 거의 100 %의 캐시 적중률을 얻으므로 메모리는 문제가되지 않습니다.
내가 달릴 때 :
SELECT * FROM sys.dm_os_wait_stats
order by signal_wait_time_ms desc
나는 얻었다 :
wait_type waiting_tasks_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 WRITELOG 16850119 18328365 1193 2367880 PAGELATCH_EX 13254618 8524515 11263 1670113 ASYNC_NETWORK_IO 23954146 6981220 7110 1475699 (10 행 영향을 받음)
나도 달렸다
-- 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
그리고있어
wait_type wait_time_s pct running_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
병렬 처리 (높은 CXPACKET)와 관련된 쿼리를 동기화하는 데 많은 시간이 소요됩니다. 또한, 이러한 많은 문제 쿼리가 여러 코어에서 실행되고있는 경우도 있습니다 (코드의 어느 곳에도 MAXDOP 힌트가 없습니다)
서버가 하루 이상로드되지 않았습니다. 쿼리 실행에 많은 차이가 있으며 일반적으로 많은 쿼리가 이전 DB 서버에 비해 느리고 CPU가 실제로 높습니다.
하이퍼 스레딩을 비활성화하면 CPU 사용량을 줄이고 처리량을 늘리는 데 도움이됩니까?
1
참조 : ozamora.com/2010/09/sql-server-2008-r2-and-nehalem-processors 및 ozamora.com/2010/09/…
—
Sam Saffron
CXPACKET이 프로세스가 병합되기를 기다리는 데 시간이 많이 걸리는 것은 아닙니다. CXPACKET은 스레드가 다른 스레드가 처리를 완료하기를 기다리고 있음을 의미합니다. CXPACKET 대기에 스레드가있는 특정 쿼리를보고 CXPACKET 외에 다른 스레드가 대기중인 항목을 확인해야합니다. 일반적으로 IO 또는 네트워크입니다. 위의 출력에서 래치를 기다리고 일정을 잡고 있습니다. 일부 쿼리를 조정해야하거나 왜 래치가 걸리는지 알아야합니다.
—
mrdenny
우리의 경우 CXPACKET은 다른 스레드가 캐시에서 과도하게 읽기 때문에 쿼리 당 2 천만 개의 논리적 읽기이므로 CXPACKET이 높았습니다. 우리의 경우는 다시 분할 된 테이블이 700K 행에 불과한 잘못된 반 세미 조인이었습니다.
—
ozamora
@mrdenny, 그렇습니다. 높은 래치 대기 시간은 현재 조사 중입니다.
—
Sam Saffron