SQL Server. Кто-нибудь использует SUMA, флаг трассировки 8048 или флаг трассировки 8015?

Недавно включен флаг трассировки запуска SQL Server 8048 для решения серьезной проблемы конфликта спин-блокировок в системе 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 за представленным , -NUMA-узел может-потребность-следовой флаг-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

Gory детали системной нагрузки, собранные метрики из проблемной системы и собранные метрики из системы после вмешательства вмешательства.

Флаг трассировки 8048 был «исправлен», но было ли это лучшим решением? Будет ли SQL Server игнорировать физический NUMA из-за флага трассировки 8015, выполнил бы то же самое? Как насчет настройки BIOS для чередования памяти, оставляя серверу с SMP-имитацией поведение SUMA вместо поведения NUMA?

Мир! tw: @sql_handle

О системе: - 4 шестнадцатеричных ядра Xeon E7540 @ 2,00 ГГц, гиперпотоковое - 128 ГБ ОЗУ - WS2008R2 - MSSQL 2008 R2 SP2 - maxdop 6

О рабочей нагрузке: - 1000 с. Пакетных запланированных / поставленных в очередь отчетов, управляемых с 2 серверов приложений отчетов. - 3 вида пакетов: ежедневно, еженедельно, ежемесячно - все подключения серверов приложений отчетов к SQL Server выполняются как одна учетная запись службы - максимальный параллелизм отчета = 90

Основные выводы по проблемной системе: - От Perfmon, 15-секундные интервалы - - Система остается на 95% -100% загруженной ЦП - - Поиск страниц буфера SQL Server <10000 в секунду

• От ожидания и спин-блокировки DMV, 5-минутные интервалы
• • Высокие официанты CMEMTHREAD и время ожидания
• • Высокие SOS_SUSPEND_QUEUE спины и откаты

Сообщение в блоге инженера CSS Боба Дорра о флаге трассировки 8048 указывает, что системы с более чем 8 ядрами на узел NUMA могут столкнуться с подобными симптомами из-за узкого места в предоставлении памяти запросов. Флаг трассировки 8048 изменит стратегию на ядро, а не на узел 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, и это может быть причиной вашей проблемы. С помощью soft 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