Устранение неполадок SOS_SCHEDULER

Запустив нашу корпоративную 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, и я погуглил и обнаружил, что оно, как правило, связано с неспособностью процессора работать.

Затем я выполнил этот запрос несколько раз подряд.

SELECT *
FROM sys.dm_os_schedulers
WHERE scheduler_id < 255

Я знаю, что должен искать планировщики с ненулевым runnable_tasks_count или pending_disk_io_count, но он практически нулевой почти все время.

Я должен также упомянуть, что Максимальная степень параллелизма была установлена на 1, поскольку рабочая нагрузка Dynamics AX обычно имеет OLTP-характер, и ее изменение 8 не имело большого значения в приведенной выше статистике ожидания, они стали почти одинаковыми с той же проблемы с производительностью.

Я вроде в недоумении, куда идти дальше, у меня в основном есть SQL Server, который, по-видимому, связан с процессором, но не ожидает runnable_tasks или IO.

Я знаю, что подсистема ввода-вывода этого SQL Server не очень хороша, потому что запуск SQLIO на диске, содержащем фактические базы данных, может привести к довольно низким числам (например, 10 МБ в секунду для определенных типов чтения / записи), что говорит: Похоже, что SQL этого не ждет, потому что объем памяти на сервере кэширует большинство баз данных.

Вот некоторая информация об окружающей среде, чтобы помочь:

Производственная среда:

SQL Server
HP ProLian DL360p Gen8
Intel Xeon E5-2650 0 @ 2,00 ГГц x 2 с гиперпоточностью (32 логических ядра)
184 ГБ памяти
Windows Server 2012
2 экземпляра SQL Server 2012 Standard (окончательная первоначальная версия, без исправлений)
Raid 1 279GB накопителей (15k) C: диск, содержит базы данных и операционную систему
Файл подкачки и TempDB на отдельных, отдельных дисках (твердотельные)

Мой DEV:

Сервер Hyper-V, размещенный на сервере SQL Server и Dynamics AX 2012 AOS
Core i7 3.4 ГГц с гиперпоточностью (8 логических ядер)
8 ГБ памяти
Windows Server 2008 R2
SSD для всей ВМ.

Я приветствовал бы любой вклад в другие вещи, чтобы искать.

— Николас Петерсон
источник

Таким образом, я решил эту проблему, оказалось, что функции управления питанием были включены на нашем сервере SQL, которые увеличивали частоту процессора вверх и вниз, но не достаточно быстро, чтобы справиться с небольшими требованиями, и ввели ожидание SOS_Scheduler_Yield. После того, как он стал работать всегда с высокой производительностью, проблема исчезла, и теперь ожидания стали более нормальными (тип LatchIO).

— Николас Петерсон
источник

Устранение неполадок SOS_SCHEDULER_YIELD ждать