회사 ERP (Dynamics AX 2012)를 운영하면서 프로덕션 환경이 개발 시스템보다 훨씬 느리다는 것을 알았습니다.
추적을 실행하는 동안 개발 환경과 프로덕션 환경 모두에서 동일한 활동을 수행 한 후 개발과 비교하여 프로덕션 환경에서 SQL 쿼리가 매우 느리게 실행되고 있음을 확인했습니다 (평균 10-50 배 느림).
처음에는이 작업을로드 한 것으로 간주하고 근무 외 시간 동안 프로덕션 환경에서 동일한 활동을 다시 실행하여 동일한 결과를 추적에서 찾았습니다.
SQL Server에서 대기 통계를 지우고 서버가 정상적인 프로덕션로드에서 잠시 동안 실행되도록 한 다음이 쿼리를 실행했습니다.
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'CLR_SEMAPHORE', N'LAZYWRITER_SLEEP',
N'RESOURCE_QUEUE', N'SQLTRACE_BUFFER_FLUSH',
N'SLEEP_TASK', N'SLEEP_SYSTEMTASK',
N'WAITFOR', N'HADR_FILESTREAM_IOMGR_IOCOMPLETION',
N'CHECKPOINT_QUEUE', N'REQUEST_FOR_DEADLOCK_SEARCH',
N'XE_TIMER_EVENT', N'XE_DISPATCHER_JOIN',
N'LOGMGR_QUEUE', N'FT_IFTS_SCHEDULER_IDLE_WAIT',
N'BROKER_TASK_STOP', N'CLR_MANUAL_EVENT',
N'CLR_AUTO_EVENT', N'DISPATCHER_QUEUE_SEMAPHORE',
N'TRACEWRITE', N'XE_DISPATCHER_WAIT',
N'BROKER_TO_FLUSH', N'BROKER_EVENTHANDLER',
N'FT_IFTSHC_MUTEX', N'SQLTRACE_INCREMENTAL_FLUSH_SLEEP',
N'DIRTY_PAGE_POLL', N'SP_SERVER_DIAGNOSTICS_SLEEP')
)
SELECT
[W1].[wait_type] AS [WaitType],
CAST ([W1].[WaitS] AS DECIMAL(14, 2)) AS [Wait_S],
CAST ([W1].[ResourceS] AS DECIMAL(14, 2)) AS [Resource_S],
CAST ([W1].[SignalS] AS DECIMAL(14, 2)) AS [Signal_S],
[W1].[WaitCount] AS [WaitCount],
CAST ([W1].[Percentage] AS DECIMAL(4, 2)) AS [Percentage],
CAST (([W1].[WaitS] / [W1].[WaitCount]) AS DECIMAL (14, 4)) AS [AvgWait_S],
CAST (([W1].[ResourceS] / [W1].[WaitCount]) AS DECIMAL (14, 4)) AS [AvgRes_S],
CAST (([W1].[SignalS] / [W1].[WaitCount]) AS DECIMAL (14, 4)) AS [AvgSig_S]
FROM [Waits] AS [W1] INNER JOIN [Waits] AS [W2] ON [W2].[RowNum] <= [W1].[RowNum]
GROUP BY [W1].[RowNum], [W1].[wait_type], [W1].[WaitS],
[W1].[ResourceS], [W1].[SignalS], [W1].[WaitCount], [W1].[Percentage]
HAVING SUM ([W2].[Percentage]) - [W1].[Percentage] < 95; -- percentage threshold
내 결과는 다음과 같습니다.
WaitType Wait_S Resource_S Signal_S WaitCount Percentage AvgWait_S AvgRes_S AvgSig_S
SOS_SCHEDULER_YIELD 4162.52 3.64 4158.88 4450085 77.33 0.0009 0.0000 0.0009
ASYNC_NETWORK_IO 457.98 331.59 126.39 351113 8.51 0.0013 0.0009 0.0004
PAGELATCH_EX 252.94 5.14 247.80 796348 4.70 0.0003 0.0000 0.0003
WRITELOG 166.01 48.01 118.00 302209 3.08 0.0005 0.0002 0.0004
LCK_M_U 145.47 145.45 0.02 123 2.70 1.1827 1.1825 0.0002
그래서 가장 큰 대기는 SOS_Scheduler_Yield이며, 나는 주변을 둘러 보았으며 일반적으로 CPU가 유지할 수없는 것과 관련이 있음을 알았습니다.
그런 다음이 쿼리를 연속해서 여러 번 실행했습니다.
SELECT *
FROM sys.dm_os_schedulers
WHERE scheduler_id < 255
runnable_tasks_count 또는 pending_disk_io_count가 0이 아닌 스케줄러를 찾고 있어야하지만 기본적으로 거의 항상 0입니다.
또한 Dynamics AX 워크로드는 일반적으로 OLTP이므로 최대 병렬 처리 수준이 1로 설정되어 있으며 8을 변경해도 위의 대기 통계에서 큰 차이가 없었으므로 거의 동일하게 동일하게 변경되었습니다. 성능 문제.
나는 여기서 갈 곳을 잃어 버렸습니다. 기본적으로 CPU 끈이 있지만 runnable_tasks 또는 IO를 기다리지 않는 SQL Server가 있습니다.
실제 데이터베이스를 포함하는 드라이브에서 SQLIO를 실행하면 숫자가 매우 낮아질 수 있기 때문에 (특정 유형의 읽기 / 쓰기에 대해 초당 10MB를 생각할 수 있음)이 SQL Server의 IO 하위 시스템이 좋지 않다는 것을 알고 있습니다. 대부분의 데이터베이스를 캐싱하는 서버의 메모리 양으로 인해 SQL이 대기하는 것처럼 보이지 않습니다.
다음은 도움이되는 환경 정보입니다.
생산 환경 :
- SQL 서버
- HP ProLian DL360p Gen8
- 하이퍼 스레딩이있는 Intel Xeon E5-2650 0 @ 2.00GHz x 2 (32 개의 논리 코어)
- 184GB 메모리
- Windows Server 2012
- SQL Server 2012 Standard 인스턴스 2 개 (RTM, 패치되지 않음)
- Raid 1 279GB 드라이브 (15k) C : 드라이브, 데이터베이스 및 운영 체제 포함
- 별개의 별도 드라이브에있는 페이지 파일 및 TempDB (솔리드 상태)
내 장치 :
- Hyper-V 호스팅 SQL Server 및 Dynamics AX 2012 AOS 서버
- 하이퍼 스레딩이있는 Core i7 3.4ghz (8 개의 논리 코어)
- 8GB 메모리
- Windows Server 2008 R2
- 전체 VM에 대한 SSD.
다른 것들에 대한 의견을 환영합니다.