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


21

Недавно включен флаг трассировки запуска 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? Если это так, то, я думаю, в кеше пула буферов у системы будет всего несколько страниц базы данных. Если нет, следует ли уменьшить максимальную память сервера для соответствия?

Ответы:


12

Это потрясающий пост.

Чтобы ответить на ваш последний вопрос, я бы предположил, что ваш ответ «да».

Тем не менее, я, вероятно, следовал бы за мягкой нума прежде, чем прибегнуть к флагам трассировки. Я думаю, что вы правы насчет распределения узлов 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

Спасибо за упоминание sys.dm_os_nodes и sys.dm_os_waiting_tasks. Я пишу ряд хранимых процедур для профилирования деятельности системы, сначала для достижения некоторой оптимизированной базовой линии, а затем для отслеживания отклонений. Прямо сейчас запись ожиданий и вращений, затем следует предоставление памяти (включая допинг на предоставление памяти) ... следующие отдельные официанты и узлы, как вы обсуждали ... затем, возможно, к клеркам памяти и счетчикам кэша ...
sql_handle

1
Другой интересный счетчик, который стоит посмотреть - это perfmon: SQLServer: Buffer Node :. Счетчиками в этой интересующей семье являются иностранные страницы, свободные страницы, ожидаемая продолжительность жизни страниц, общее количество страниц, целевые страницы и украденные страницы. Я предполагаю, что до того, как вы применили флаг трассировки, у вас было очень большое количество посторонних страниц - у вас включен TF 834? Если так, я обнаружил, что он не распределяет память для каждого узла numa сбалансированным образом, что приводит к очень большому количеству дорогостоящих поисков памяти удаленных узлов numa. Система, на которой я имел эту проблему, содержала 1 ТБ оперативной памяти в то время.
Джереми Лоуэлл

хорошие моменты. Я наблюдал за метрикой узла буфера. Самым любопытным было то, что изначально у узла 00 не было посторонних страниц, а у других узлов было огромное количество. Я думаю, это произошло из-за того, что наш ETL выполнил наращивание буфера с достаточно низким числом потоков, чтобы полностью уместиться на узле буфера / узле NUMA 00. У нас не включен флаг трассировки 834, но мы скоро начнем тестирование с ним. Наше тестирование рабочей нагрузки на Linux Oracle 11gR2 показало большую выгоду для больших страниц памяти, я думаю, что мы увидим преимущества и в Windows с SQL Server.
sql_handle

@Mike Soft NUMA против TF 8048. Я думаю, что soft NUMA позволил бы мне создавать «узлы памяти» в узлах NUMA. Поэтому, если бы я создал мягкую NUMA для каждого ядра, было бы (возможно) 24 полосы для запросов на предоставление памяти в запросах. Но, может быть, также 24 узла памяти? Я бы немного беспокоился о накладных расходах при управлении 24 узлами памяти, когда каждое ядро ​​создает «чужие» ссылки на страницы каждый раз, когда оно пересекает мягкую границу NUMA, и действительно внешние ссылки, когда оно пересекает границу для ссылки на страницу, которая отличается мягкая НУМА и жесткая НУМА. Я попробую и посмотрю, смогу ли я что-нибудь различить.
sql_handle
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.