SQL Server Service Broker: как определить издержки или максимальную производительность?

Question

Мы пытаемся определить, правильно ли мы используем Service Broker и получаем от этого максимальную производительность. Мы настраивали наши разговоры и обработку SB и перешли с 3000 в минуту на 8000 в минуту, но CPU остался постоянным на уровне 100%. Кроме того, в некоторые дни очередь SB остается пустой, но в дни с похожим трафиком очередь может создать резервную копию на 500 тыс.

Машина представляет собой четырехъядерный процессор (16 ядер), без HT, 32 ГБ ОЗУ и 26 ГБ, назначенных для SQL Server, с включенным AWE.

SQL Server 2008 с пакетом обновления 1 (без CU), выпуск Enterprise Edition. Microsoft SQL Server 2008 (SP1) - 10.0.2531.0 (X64) 29 марта 2009 г. 10:11:52 Copyright (c) 1988-2008 Microsoft Corporation Enterprise Edition (64-разрядная версия) в Windows NT 6.1 (сборка 7600:)

Сообщения вставляются в очередь компонента Service Broker, которая извлекает группы сообщений и пропускает их через CLR, который анализирует XML (а не простой анализ, увы) и вставляет в таблицу. CLR значительно быстрее, чем наш код T-SQL.

У нас в среднем 35 выполняемых задач на планировщик

Мы запускаем еженедельную поддержку статистики / индекса.

Мы установили сервер MAXDOP = 1, чтобы повысить производительность.

Мы увеличили количество файлов tempdb до 64, чтобы избежать конфликта SGAM, что в сочетании с TF1118, по-видимому, остановило конфликт TEMPDB.

Глядя на sys.dm_os_waiting_tasks, мы обычно имеем ~ 60 задач, ожидающих в THREADPOOL, и только несколько других типов.

Наш сигнал ожидания составляет 70% (ресурс ожидает = 30%).

Мы убедились, что TokenAndUserPermCache остается менее 20 МБ.

Глядя на sys.dm_os_latch_stats, мы видим 40-200k защелок BUFFER за 1 минуту, которые в основном находятся на sysdesend и пользовательской таблице, которую мы используем для работы с диалогами.

Мы также видим высокий SOS_SCHEDULER_WAIT, который также указывает на нагрузку на процессор. Но это из-за необычайно загруженного CLR или из-за издержек Service Broker? Я с радостью предоставлю код - дайте мне знать, что мне нужно опубликовать здесь.

Заранее спасибо.

Answer 1

1. Используете ли вы SSB только в качестве локального механизма организации очередей / обработки, или есть какая-либо удаленная доставка сообщений (передача по x-машине)?
2. Сколько очередей?
3. Включена ли активация, я полагаю, да, сколько max_queue_readers?
4. Что-нибудь, что вы можете ассоциировать с шипами 500 тыс.?Сколько времени у них уходит?

Некоторые кадры в темноте:

• Если вы видите конфликт буфера из-за sysdesend / sysderecv, вы можете попробовать это:1014 * Технический документ Service Broker в MSDN: уловка 150 .
• Убедитесь, что очистка от призрака соответствует задаче, см. Работа с большими очередями .Skipped Ghost Records/sec уходит с графиков?

~ 60 задач, ожидающих рабочих на 16-процессорной машине ... Обычно я считаю, что все в порядке, но для машины, предназначенной для обработки SSB, это немного странноТак как такие машины, как правило, имеют мало долго выполняемых задач (активированных заданий), в отличие от многих краткосрочных, они не склонны показывать ожидание THREADPOOL.