Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Непонятнки с Service broker (MAX_QUEUE_READERS)  [new]
orunbek
Member

Откуда: Гималай
Сообщений: 2101
Доброго времени суток.

Это мой первый проект с использованием Service Broker.
Есть таблица данных, которые нужно обработать через различные web-сервисы, в зависимости от типа запроса.
Система очереди держится на Service Broker, сервер БД SQL Server 2008 R2.
Очередь в Service Broker к примеру называется SB_Queries_TargetQuee, очереди обрабатываются CLR хранимкой.
MAX_QUEUE_READERS равен 200:
CREATE QUEUE [dbo].[SB_Queries_TargetQueue]
WITH STATUS = ON ,
RETENTION = OFF ,
ACTIVATION (
     STATUS = ON ,
     PROCEDURE_NAME = [dbo].[CLR_SP_QueryProcessor] ,
     MAX_QUEUE_READERS = 200 , EXECUTE AS OWNER  ),
POISON_MESSAGE_HANDLING (STATUS = OFF)  ON [PRIMARY] 


И я периодически мониторю очередь и количество запущенных CLR хранимок следующим образом.
Количество "активированных" хранимок:
select * from sys.dm_broker_activated_tasks

Количество записей в очереди:
SELECT COUNT(*) FROM SB_Charges_TargetQueue WITH(NOLOCK)


При этом в очереди всегда есть записи, т.е. еще не обработанные хранимкой, и количество "активированных" хранимок, не превышает 10ти, хотя MAX_QUEUE_READERS равен 200.
Данные из очереди читаются следующим образом:
WAITFOR (RECEIVE TOP (1) conversation_handle, message_type_name, message_body FROM SB_Queries_TargetQueue), TIMEOUT 500


Подскажите пожалуйста, в чем может быть проблема.
Спасибо.
15 июл 12, 08:27    [12868569]     Ответить | Цитировать Сообщить модератору
 Re: Непонятнки с Service broker (MAX_QUEUE_READERS)  [new]
orunbek
Member

Откуда: Гималай
Сообщений: 2101
Забыл добавить, непосредственное чтение записей из очереди SB_Queries_TargetQueue делается из CLR-хранимки.

Может быть решение проблемы будет в выносе чтения очереди в хранимку на T-SQL?
И затем передавать полученную запись в CLR-хранимку?
Буду пробовать, но хотелось бы услышать еще мнения.
15 июл 12, 08:28    [12868572]     Ответить | Цитировать Сообщить модератору
 Re: Непонятнки с Service broker (MAX_QUEUE_READERS)  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Обработка сообщений не "жадная", только если в очереди растёт количество сообщений, тогда активируется новый обработчик.
Если текущие справляются, это не значит, что в очереди не должно быть сообщений.

Выбирайте TIMEOUT такой, чтобы не было такого, что процедуры не успевают дождаться очередного сообщения, и постоянно заканчиваются и активируются. Но и не такой, что большинство процедур "простаивают" и "дерутся" за сообщения.

Или у вас очередь "захлёбывается"?
15 июл 12, 14:33    [12869149]     Ответить | Цитировать Сообщить модератору
 Re: Непонятнки с Service broker (MAX_QUEUE_READERS)  [new]
orunbek
Member

Откуда: Гималай
Сообщений: 2101
Обработка одного запроса занимает минимум 1 секунду, максимум до 5ти секунд.
Логика обработки сообщений в CLR хранимке такова, проверяется наличие записей в очереди с таймаутом в 500 мс в транзакции, после того как запись взята, транзакция сразу закрывается и дальше идет обработка через web-сервис.
И в этот момент, скажем обработка записи в CLR хранимке длится больше 3-4 секунд, и во время обработки в очереди есть запись.
Почему SB не активирует хранимки для обработки следующих записей из очереди?
Как добиться того, чтобы запускалось именно столько обработчиков сколько указано в MAX_QUEUE_READERS?
Т.е. в очереди 500 записей, MAX_QUEUE_READERS=100, 100 обработчиков запускаются и после обработки записи, каждый обработчик берет следующую запись в цикле, до тех пор пока очередь не будет пустой.
По поводу захлебывания, максимальное количество записей в очереди достигало 100 записей, в среднем 5-15, но обработка данных очень критична. И задержка обраотки записей из очереди больше чем на 10 секунд создает проблему.
15 июл 12, 19:07    [12869685]     Ответить | Цитировать Сообщить модератору
 Re: Непонятнки с Service broker (MAX_QUEUE_READERS)  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Как вы замысловато написали, притом не понятно, вы либо не поняли что я написал, либо так странно "возмущаетесь", что оно не делает то, как вам казалось должно делаться. Притом повторили то, что вы написали в начале, словно мы не поняли, что вы имели ввиду.
То что вы ожидаете от очередей (в SB), ожидают многие, но:

Очереди в принципе, по своему смыслу, не есть асинхронная обработка в чистом виде.

Вспоминается микроскоп и гвозди.

orunbek
проверяется наличие записей в очереди с таймаутом в 500 мс в транзакции, после того как запись взята, транзакция сразу закрывается и дальше идет обработка через web-сервис.
Омг. А если проца упала (банально сервер перегрузили)? Всё, хамба сообщению?
Ок, ну зачем тогда транзакция вообще?
Не, что-то вы недопонимаете.
=======================================================

А вот как организовать чистую асинхронность на скуле? Ну можно и тот же SB, неважно (Job тоже отлично подходит), нужно забирать сразу все "сообщения" и создавать на каждый свой отдельный поток. Ну в принципе в ссылке выше так и описано (см. scheduler).
15 июл 12, 21:17    [12869944]     Ответить | Цитировать Сообщить модератору
 Re: Непонятнки с Service broker (MAX_QUEUE_READERS)  [new]
orunbek
Member

Откуда: Гималай
Сообщений: 2101
"Сохранность" записи из очереди на случай падения базы или сервера обеспечена.
Я описал только момент работы SB.
А MAX_QUEUE_READERS чтобы контролировать количество активированных обработчиков, если же реализую вариант чтения всей очереди и активирования столько же хранимок, то не будет контроля количества запущенных обработчиков.
Или нужно будет свой велосипед придумывать, для этой цели.
В "начале", т.е. до того пока я не узнал про SB, я задумывал именно такой вариант решения проблемы, т.е. запускается обработчик и активирует в потоке именно столько обработчиков сколько в очереди записей, но без SB.
Затем узнал в этом форуме про SB с возможностью контролирования количества активированных обработчиков и поэтому и перешел на SB.
В принципе, меня все устраивает в SB, асинхронность, контроль блокировок, вопрос только в контроле запущенных обработчиков очереди, а именно MAX_QUEUE_READERS.
16 июл 12, 06:59    [12870673]     Ответить | Цитировать Сообщить модератору
 Re: Непонятнки с Service broker (MAX_QUEUE_READERS)  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
orunbek
"Сохранность" записи из очереди на случай падения базы или сервера обеспечена.
Значит вы в той транзакции делаете что-то ещё (меняете состояния к примеру)

orunbek
обработка данных очень критична. И задержка обработки записей из очереди больше чем на 10 секунд создает проблему.
...
нужно контролировать количество активированных обработчиков
Противоречие однако.
Вам не понятна столь очевидная вещь.
Ай ну да, у гималайцев всегда так, у всех!

orunbek
Затем узнал в этом форуме про SB с возможностью контролирования количества активированных обработчиков и поэтому и перешел на SB.
То, что у пула "появился" параметр "ограничение сверху", не заначит что там нет(небыло) очереди.

Ok, понять вы не хотите, ладно.
Увеличте TIMEOUT. Не решит "проблему", но уменьшит "эффект".

Давайте вы не будете говорить что вам надо, а я не буду восприниматься как разработчик MS. Ok?!
Вот выдержка из BOL. А дальше ...тесь как хотите (с)
BOL
Активация является необходимой, если верно одно из следующих условий.

  • Новое сообщение прибывает в очередь, где не содержатся непрочитанные сообщения, и для этой очереди не запущены хранимые процедуры активации.

  • Очередь содержит непрочитанные сообщения, отсутствует ожидающий сеанс в инструкции GET CONVERSATION GROUP или инструкции RECEIVE без предложения WHERE, а инструкция GET CONVERSATION GROUP или инструкция RECEIVE без предложения WHERE в течение нескольких секунд возвращала пустой результирующий набор. Иными словами, сообщения накапливаются в очереди, поскольку активируемые процедуры не успевают их считывать.
  • 16 июл 12, 10:17    [12871068]     Ответить | Цитировать Сообщить модератору
     Re: Непонятнки с Service broker (MAX_QUEUE_READERS)  [new]
    orunbek
    Member

    Откуда: Гималай
    Сообщений: 2101
    В транзакции выполняется только чтение записи из очереди, затем транзакция закрывается и после этого передается обработчику
    Даже если SB упадет, или будут проблемы с очередью, сохранность запросов из очереди обеспечна другой логикой, но в этом суть проблемы
    Вопрос был в количестве активированных SB (MAX_QUEUE_READERS).
    Попробую другими средствами придумать количество активированных хранимок
    16 июл 12, 11:18    [12871488]     Ответить | Цитировать Сообщить модератору
    Все форумы / Microsoft SQL Server Ответить