Усунення несправностей SOS_SCHEDULER_YIELD зачекайте

Запускаючи наш корпоративний 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

Так що, здавалося б, найбільший Wait - це 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-сервера не дуже хороша, тому що запуск SQLIO на накопичувачі, що містить фактичні бази даних, може призвести до досить низьких цифр (думаю, 10 Мб в секунду для певних типів читання / запису), не здається, що SQL чекає на це через кількість пам’яті на сервері, що кешує більшість баз даних.

Ось декілька відомостей про навколишнє середовище:

Виробниче середовище:

• SQL Server
• HP ProLian DL360p Gen8
• Intel Xeon E5-2650 0 @ 2.00GHz x 2 із гіперточенням (32 логічних ядра)
• 184 Гб пам'яті
• Windows Server 2012
• 2 екземпляри стандарту SQL Server 2012 (RTM, без виправлень)
• Raid 1 накопичувачі 279 Гб (15 К) C: накопичувач, містить бази даних та операційну систему
• Файл сторінки та TempDB на окремих, окремих накопичувачах (твердому стані)

Мій DEV:

• Hyper-V розмістив сервер AOS SQL і Dynamics AX 2012
• Core i7 3.4 ГГц з гіперточенням (8 логічних ядер)
• 8 Гб пам'яті
• Windows Server 2008 R2
• SSD для всього VM.

Я вітаю будь-які дані щодо інших речей, які потрібно шукати.

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