SQL Server - Хто-небудь використовує SUMA, прапор трас 8048 або прапор трас 8015?

Нещодавно включений запуск Trace Flag 8048 для запуску SQL Server для вирішення серйозних проблем із суперечкою відключення в системі SQL Server 2008 R2.

Цікаво почути від інших, хто знайшов випадки використання, коли значення продуктивності передається прапором 8048 сліду (сприяє стратегії надання пам’яті запитів від вузла NUMA до ядра), прапор трасування 8015 (SQL Server ігнорує фізичну NUMA) або SUMA ( достатньо рівномірний доступ до пам'яті, опція BIOS на деяких машинах NUMA).

Слідовий прапор 8048 http://blogs.msdn.com/b/psssql/archive/2011/09/01/sql-server-2008-2008-r2-on-newer-machines-with-more-than-8-cpus -presented-per-numa-node-may-need-trace-flag-8048.aspx

Прапор сліду 8015 http://blogs.msdn.com/b/psssql/archive/2010/04/02/how-it-works-soft-numa-io-completion-thread-lazy-writer-workers-and-memory -nodes.aspx

Прослідкуйте детальну інформацію про завантаженість системи, зібрані показники з проблемної системи та зібрані показники з системи після втручання.

Слід трас 8048 був "виправленням", але чи було це найкращим виправленням? Чи вдалося б ігнорувати SQL Server фізичну NUMA через прапор 8015 сліду? Що з налаштування BIOS для перемежування пам’яті, залишаючи сервер з поведінкою SUMA, що імітує SMP, замість поведінки NUMA?

Мир! tw: @sql_handle

Про систему: - 4-хекс. Ядро Xeon E7540 при 2,00 ГГц, гіперточена - 128 ГБ оперативної пам’яті - WS2008R2 - MSSQL 2008 R2 SP2 - maxdop 6

Про навантаження: - 1000 тисяч пакетних звітів, запланованих / в черзі, керованих з двох серверів додатків звітів. - 3 різновиди пакетів: щодня, щотижня, щомісяця - Усі підключення серверів додатків звітів до SQL Server здійснюються як єдиний обліковий запис сервісу - Максимальна сумісність звіту = 90

Основні висновки щодо проблемної системи: - від Perfmon, 15-секундні інтервали - - Система залишається зайнятою на 95% -100% процесора - - пошук сторінок буфера SQL Server <10000 в секунду

• З ДМВ на очікування та закрутки, інтервали 5 хвилин
• • Високі офіціанти CMEMTHREAD та час очікування
• • Високі SOS_SUSPEND_QUEUE крутиться та відтворює

Публікація в блозі Боб Дорра в CSS Engineer про траєкторію 8048 вказує, що системи з більш ніж 8 ядрами на вузлі NUMA можуть зіткнутися з подібними симптомами через вузьке місце в наданні пам’яті запитів. Прапор трасування 8048 змінить стратегію на ядро ​​замість вузла per-NUMA.

Втручання

MSSQL було перезапущено з -T8048 на місці. Різниця була очевидною: швидкість пошуку буферної сторінки зросла понад 1 мільйон і зросла до 8 мільйонів в секунду. Проблемне навантаження, яке раніше не могло завершитись за 24 години, завершилося менше ніж за 4 години. Інша партійна навантаження, яка не була в центрі уваги розслідування чи втручання, була подана як частина перевірки коригуючого значення прапора 8048 сліду (і забезпечення того, щоб його небажані побічні ефекти були мінімальними). Цю партію звітів попередньо завершили за 2 години; зі слідом 8048 на місці партії звіту завершено приблизно за 20 хвилин.

Нічні ETL також стикалися з вигодою. Час ETL знизився приблизно з 60 хвилин до 40 хвилин.

Збираючи інформацію з декількох місць, я припускаю, що високий ступінь черги звітів, кількість одночасних звітів більше, ніж кількість апаратних ниток, і єдиний обліковий запис користувача для всіх звітів, що поєднують тиск на один вузол NUMA, поки тиск робочої нитки не призведе до не буде сприйнято наступний запит на вхідне з'єднання для того самого облікового запису користувача, і тоді наступний вузол NUMA отримає деяку кількість з'єднань. Кожен вузол NUMA закінчується великою ймовірністю підкреслити вузьке місце в пам'яті запитів.

Відкривши більше смуг для надання пам’яті запитів, видалено вузьке місце. Але, я не впевнений у витратах. Повідомлення CSS Боба Дорра дає зрозуміти, що є додаткові накладні об'єм пам’яті з прапором 8048. Це накладні витрати в межах однієї сторінки алокатора, керованої пам'яттю сервера MSSQL 2008 R2 max? Якщо так, то, мабуть, у системі буде просто деяка кількість сторінок баз даних у кеш-пулі пулу. Якщо ні, чи слід знизити максимальну пам'ять сервера для розміщення?

Це приголомшливий пост.

Щоб відповісти на ваше остаточне запитання, я б припускав, що ваша відповідь - так.

Однак, я, мабуть, переслідував би м'яку нуму, перш ніж вдаватися до слідів. Я думаю, ти маєш рацію щодо розподілу вузла numa, і це може бути в основі вашої проблеми. Через м'яку нуму ви можете масштабувати запити, залежно від вашого числа вузлів numa (4?) - до 4, якщо це правильне число, а потім присвоювати через ip адресу кожному хосту певний вузол numa, крім того до цього я б відключив гіпер-нарізку. У поєднанні це питання, ймовірно, зменшиться, однак це зробить це ціною меншої кількості планувальників.

На думку окремо, я б розглядав примусову параметризацію - дуже цікавим є той факт, що ваше навантаження приводить ваш центральний процесор настільки високо, і, можливо, варто це вивчити.

Нарешті, у системах з багаточисельними вузлами я, як правило, отримую висновки з наступних запитів, що скидаються до таблиці кожні N секунд. Здійснює цікавий аналіз, коли впроваджуються зміни завантаженості чи прапорці слідів:

SELECT getdate() as poll_time, node_id, node_state_desc, memory_node_id, online_scheduler_count, active_worker_count, avg_load_balance, idle_scheduler_count
FROM sys.dm_os_nodes WITH (NOLOCK) 
WHERE node_state_desc <> N'ONLINE DAC'

і

SELECT top 10 getdate() as sample_poll, wait_type, count (*)
FROM sys.dm_os_waiting_tasks
WHERE [wait_type] NOT IN
('CLR_SEMAPHORE','LAZYWRITER_SLEEP','RESOURCE_QUEUE','SLEEP_TASK','SLEEP_SYSTEMTASK',
'SQLTRACE_BUFFER_FLUSH','WAITFOR', 'BROKER_TASK_STOP',
'BROKER_RECEIVE_WAITFOR', 'OLEDB','CLR_MANUAL_EVENT', 'CLR_AUTO_EVENT' ) 
GROUP BY wait_type
ORDER BY COUNT (*) DESC