Коллекции являются одним из ключевых элементов Configuration Manager. Приложения, обновления, конфигурационные элементы, политики – все это назначается на коллекции, и если с коллекциями начались проблемы, вы это быстро почувствуете.
Если вы нашли эту статью, пытаясь срочно разрешить уже возникшие проблемы со скоростью работы коллекций, переходите сразу к разделу “Устранение проблем” в конце текста.
Проблемы с коллекциями, по большей части, создают администраторы Configuration Manager, когда пишут правила членства. В особо тяжелых случаях, неудачное правило-запрос может остановить SQL серверы нескольких первичных сайтов иерархии. Эту статью я решил написать как раз после того, как я увидел такое у одного заказчика . Статья ориентирована на администраторов крупных или сильно нагруженных иерархий с несколькими сайтами и большим количеством клиентов. Если система маленькая, проблем, скорее всего, не возникнет.
Представьте себе ситуацию, когда на всех серверах SQL первичных сайтов иерархии начинает расти tempdb.log. Файл журнала Temp DB может расти только если какая-то транзакция не завершается, и продолжает собирать данные. Одновременно с этим, администраторы назначений жалуются, что все коллекции “подвисли” с “песочными часами”, и они не могут работать. Файл tempdb.log достигает размера уже 170 ГБ, место на диске с tempdb подходит к концу, SQL может встать на паузу. Если перезапустить SQL, процесс повторяется, место снова начинает заканчиваться.
Посмотреть в чём дело оказалось несложно, и об этом мы поговорим ниже. Была найдена коллекция, которая “вешала” Collection Evaluator’ы и нагружала все сервера SQL первичных сайтов иерархии.
Вот её, вроде как ничем не примечательный, WQL запрос:
select SMS_R_SYSTEM.ItemKey,
SMS_R_SYSTEM.DiscArchKey,
SMS_R_SYSTEM.Name0,
SMS_R_SYSTEM.SMS_Unique_Identifier0,
SMS_R_SYSTEM.Resource_Domain_OR_Workgr0,
SMS_R_SYSTEM.Client0
from vSMS_R_System AS SMS_R_System
INNER JOIN SB_SCCM_Programs_DATA AS SMS_G_System_SCCM_Programs
ON SMS_G_System_SCCM_Programs.MachineID = SMS_R_System.ItemKey
INNER JOIN vSMS_G_System_SoftwareFile AS SMS_G_System_SoftwareFile
ON SMS_G_System_SoftwareFile.ClientId = SMS_R_System.ItemKey
where (SMS_G_System_SoftwareFile.FileName = N'PATCHSET13.dll'
OR SMS_G_System_SCCM_Programs.PkgID00 = N'PR10028A' OR SMS_G_System_SCCM_Programs.PkgID00 = N'PR20028A'))
В среде заказчика (260 тысяч клиентов) запрос при своем выполнении “разносил” tempdb.log до 170+ ГБ, и не завершался.
Нюанс в том, что в запросе берутся все записи о компьютерах из представления v_R_System, и все файлы на этих компьютерах из v_GS_Software_File, для каждого компьютера. v_GS_Software_Files содержит данные Software Inventory, и в БД заказчика занимает объем 35 гигабайт. К этому добавляется представление SCCM_Programs из расширенной инвентаризации, содержащие перечень выполнявшихся на каждом клиенте пакетов и программ из реестра. Проще говоря, количество строк в одном представлении умножается на количество строк в остальных представлениях, и это ещё раз умножается на следующие представления. В комплекте идут два оператора ‘Or’, что тоже сказывается на скорости запроса и объеме обрабатываемых данных.
На выходе запрос выдавал десятки, а может и сотни миллионов строк, и мы не стали дожидаться его завершения. Ситуацию удалось исправить только сделав так, что все критерии в секции OR стали отдельными правилами этой коллекции, и обрабатывались отдельно. Такая коллекция наполнялась быстро и правильно.
Как работают коллекции
Прежде чем решать проблемы с коллекциями, нужно знать в общих чертах, как они работают. Представим это на примере иерархии из CAS и нескольких Primary сайтов и процесса администрирования. В этой статье мы не рассматриваем ConfigMgr 2007 и говорим лишь о последних версиях продукта.
- Администратор, подключившись консолью к CAS, создает новую коллекцию или изменяет уже имеющуюся. Он создает Collection Query Rule на языке WQL, которое по какому-то признаку отбирает компьютеры в эту коллекцию. Коллекция теперь отображается в консоли с “песочными часами”, так как ждет обновления.
- Через механизм DRS (Data Replication Service, репликация на основе собственного кода Configuration Manager в SQL Service Broker) эта коллекция попадает в БД других первичных сайтов. Коллекции глобальны, и попадают на все первичные сайты, где бы в иерархии они ни были бы созданы, то есть, если администратор подключается консолью к перичному сайту, и создает коллекцию “там”, она все равно попадает на CAS, и реплицируется на остальную иерархию. В этом случае процесс удлиняется на один шаг (Pri > CAS > Вся иерархия), поэтому работать все же рекомендуется с CAS (именно по этому он его назвали “Центральный административный сайт”).
- Компонент SMS_COLLECTION_EVALUATOR (Colleval) посредством триггеров в БД и служебных файлов в инбоксе colleval.box на каждом первичном сайте получает задание на пересчет правил членства нашей коллекции, и помещает его в один из своих пяти потоков-очередей (подробнее об этих потоках написано ниже). Если в очереди есть другие коллекции, то наша коллекция ожидает, когда обработаются те. За нашей коллекцией также может собраться очередь, пока членство в ней вычисляется. На центральном сайте компонент SMS_COLLECTION_EVALUATOR не присутствует, его там нет.
- Опять-таки на каждом первичном сайте, Colleval на сервере SQL выполняет запрос, который написал администратор в начале нашего процесса, но конвертированный из WQL в язык T-SQL. Это ключевой момент. Скорость обработки этого запроса – главное, что оказывает влияние на работу коллекций. Пока наш запрос вычисляется на сервере, другие коллекции ждут с “песочными часами”. Эту активность можно наблюдать в логе Colleval.log (включите повышенную детальность логов и SQL логирование в реестре, если хотите видеть больше), в SQL Management Studio в разделе Activity Monitor, в продвинутом случае – SQL Profiler. В работе Colleval задействована также папка инбоксов- InboxColleval.box.
- Когда членство в коллекции определено, с каждого сайта список машин через DRS посылается на CAS. Как только все первичные сайты пришлют свою часть информации, коллекция на CAS наполняется, “песочные часы” снимаются, администратор видит список компьютеров, а на первичных сайтах формируются политики из назначений, которые администратор поставил на эту коллекцию. Если на каком-то сайте линк репликации работает плохо, или SQL сервер не справляется с нагрузкой, коллекции могут “подвиснуть”, в этом один из многих недостатков иерархии из нескольких первичных сайтов и CAS.
Таким образом мы видим, что созданные самостоятельно коллекции – это фактически код, который самостоятельно создает администратор, и который выполняется в SQL. Запросы WQL система автоматически транслирует в язык запросов SQL. Сам транслированный в T-SQL запрос, как он пойдёт к базе данных, вы можете оценить в таблице Collection_Rules_SQL.
Если коллекций много, и написаны запросы неоптимально, “тормозит” написанный код, а не сам Configuration Manager. Если система большая, не стоит ждать работы в реальном времени, обновление коллекций может занимать от 10 минут до получаса и даже больше. Администраторы сами создают и должны контролировать нагрузку, то есть количество и “тяжесть” коллекций, ресурсы серверов SQL, которые не бесконечны.
Если коллекций несколько тысяч, то даже когда запросы в них не очень медленные, все равно может появиться задержка с обновлением. Это зависит от расписания обновления коллекций (вкладка Properties > Membership Rules). Когда администраторы выставляют слишком частое расписание, отдельные коллекции могут начинать обновляться раньше, чем заканчивает просчитываться предыдущий круг. Возникает очередь, и мы опять видим “песочные часы”. Как этого избежать – в разделе с рекомендациями по работе с коллекциями.
Подытожим – скорость обновления коллекций зависит от следующих факторов:
- Качество WQL запросов в правилах коллекций
- Количество коллекций и частота их обновления по расписанию
- Ресурсы и быстродействие серверов SQL
- Объем данных, из которых идет выборка
- Своевременное обслуживание БД (индексы, статистика), которое штатной Mantenance Task не обеспечивается
- Корректная работа межсайтовой репликации с первичными сайтами, если их несколько и есть CAS. Если с одним из сайтов линк отказал, коллекции могут оставаться в состоянии обновления
Потоки и работа SMS_COLLECTION_EVALUATOR
По сравнению с Configuration Manager 2007, в современных версиях продукта Colleval работает в несколько потоков. Разные виды обновления коллекций выполняются в разных потоках, это действительно важно знать, если нужно разобраться, почему плохо обновляются коллекции.
Colleval имеет четыре “основных” потока и два вспомогательных. Каждый поток является, по сути, отдельной очередью. Работу потоков можно наблюдать в логе colleval.log и дополнительной утилите CEViewer (часть Configuration Manager 2012 R2 Toolkit) .
Посмотрим, за что каждый из них отвечает:
- Primary (также известен в colleval.log как Full)- отвечает за Full Collection Update по расписанию, установленному в свойствах коллекции.
- Express (Incremental) – выполняет инкрементальное обновление тех коллекций, где оно включено.
- Manual (обозначен как Single) – здесь обрабатываются коллекции, на которых администратор выполнил Update Collection Membership. В Manual попадают коллекции, у которых нет зависимостей.
- Auxiliary является дочерним потоком Manual, и обрабатывает зависимости обновляемых вручную коллекций.
- New – Для новых коллекций есть отдельный выделенный поток. Сюда попадают только что созданные коллекции, которые сразу же начинают просчитываться.
Incremental Update
Инкрементальные обновления коллекции можно включить, поставив соответствующую отметку в ее свойствах. Термин “инкрементальный” говорит нам о том, что выборка будет производиться только из тех записей, которые изменились в таблицах, на которые направлено правило коллекции. Это позволит делать выборку не из десятков миллионов строк, а лишь из тысяч изменившихся, и сэкономить время обновления коллекции.
Как это реализовано?
На многих таблицах, содержащих данные клиентов мы можем найти триггер trCollTrack_имя_таблицы. Когда вы создаете какой-нибудь новый класс инвентаризации, триггер также появляется там. Триггер срабатывает, когда какие-то записи в таблице меняются, и помечает их для выборки инкрементальным обновлением коллекций, если у вас есть какие-то запросы, ориентированные на эту таблицу.
Обратите внимание, что на таблицах с данными CI Compliance нет таких триггеров, и инкрементальные обновление там не работает.
Частота инкрементального обновления коллекций задается в свойствах сайта, и влияет на все инкрементальные коллекции. По умолчанию эта частота – раз в 5 минут. Старайтесь, чтобы количество коллекций со включенным инкрементальным обновлением не превышало 200.
Как работает расписание?
Как известно, начиная с Configuration Manager 2012, любая коллекция должна быть ограничена (т.е. делать выборку из) какой-то коллекцией. В итоге, все иерархическое дерево коллекций компьютеров у вас ограничено All Systems. Вы можете иметь где-то расписание обновления коллекций, или нет, но каждая ваша коллекция будет обновляться хотя бы раз в сутки, а именно в 4 часа ночи. Именно в это время выполняется Full Update коллекции All Systems, который вызывает каскад полного пересчета всех запросов каждой коллекции в иерархии. И это плавно подводит нас к теме цепочек зависимости коллекций друг от друга.
Цепочки обновления коллекций и зависимости
Как известно, любые созданные нами коллекции должны быть ограничены какой-то другой коллекцией, хотя бы All Systems. Они также могут исключать членов другой коллекции (Exclude Collection) или включать их (Include Collection).
Возьмем Коллекцию А, и ограничем ее All Systems (хоть это и не рекомендуется – для наглядности). Включим (Include rule) в нее Коллекцию B. Исключим (Exclude Rule) Коллекцию С.
По логике SMS_COLECTION_EVALUATOR, теперь наша Коллекция А зависит от трех коллекций: All Systems, B и C. Компонент так устроен, что обновление и добавление нового ресурса в любой из этих коллекций вызовет обновление нашей Коллекции А.
В 4 часа ночи All Systems выполняет full update, и Коллекция А тоже будет (как и все коллекции вообще – All Systems же).
Если на Коллекции B Full Update происходит каждый час – и Коллекция А будет обновляться каждый час, вне зависимости от расписания.
Если на Коллекции А включено инкрементальное обновление, она будет обновляться так же вслед за теми из своих зависимостей, где тоже включено инкрементальное обновление, и наоборот.
Вы можете наблюдать процесс построения цепочек или таблиц зависимости (Graph) в логе Colleval.log.
Чем больше у коллекции зависимостей, тем больше она будет обрабатываться.
Рекомендации по работе с коллекциями
Документация к продукту содержит рекомендацию не включать инкрементальное обновление более чем на 200 коллекциях. Помимо этого, существуют ещё нигде не описанные правила из жизни, которые могут помочь вам ускорить работу коллекций. Советы ниже пригодятся предприятиям с количеством клиентов 10 000 и более. При малых нагрузках оптимизировать коллекции не так необходимо.
Будьте осторожны с Direct Rule – каждый раз, когда вы добавляете прямым правилом компьютер в коллекцию, это вызывает внеочередной Full Update данной коллекции, и всех коллекций, которые ограничены ей. То есть целый каскад полного обновления. Я много слышал нескольких заказчиках в Европе, которые используют Direct Rule в своем ПО автоматизации сервис деска, и которые испытывали проблемы с производительностью от десятков тысяч прямых правил.
Преимущества Query Rule перед Direct Rule:
- Возможность обновляться по расписанию, и динамически добавлять/удалять членов без вмешательства администратора.
- Query Rule может обновляться по расписанию, Direct Rule же остается привязанным к Resource ID добавленной машины навечно.
- Не требует обслуживания (написал запрос и забыл)
Отдавайте себе отчет о стоимости запросов, содержащих оператор LIKE – используете его только где необходимо.
Поменьше используйте LIKE обрамленный двумя символами ‘%’, например Where SoftwareName LIKE ‘%Office%’. Такой запрос не использует преимущества индексов на полях, и проходит через каждую строчку в столбце, что может быть в десятки раз медленней.
Старайтесь еще меньше использовать NOT LIKE. С точки зрения производительности, это то же самое, что и LIKE, только еще медленней.
Стройте коллекции по индексируемым полям таблиц. Запросы по индексированным полям работают в 10-15 раз быстрей чем запросы по “обычным” полям. Когда пишете запрос, посмотрите, нет ли подходящего индексированного поля.
Как выяснить, на каких полях существуют индексы?
Выполните следующий запрос, чтобы получить список индексированных полей в таблицах БД Configuration Manager:
SELECT
TableName = t.name,
IndexName = ind.name,
IndexId = ind.index_id,
ColumnId = ic.index_column_id,
ColumnName = col.name,
ind.*,
ic.*,
col.*
FROM
sys.indexes ind
INNER JOIN
sys.index_columns ic ON ind.object_id = ic.object_id and ind.index_id = ic.index_id
INNER JOIN
sys.columns col ON ic.object_id = col.object_id and ic.column_id = col.column_id
INNER JOIN
sys.tables t ON ind.object_id = t.object_id
WHERE
ind.is_primary_key = 0
AND ind.is_unique = 0
AND ind.is_unique_constraint = 0
AND t.is_ms_shipped = 0
ORDER BY
t.name, ind.name, ind.index_id, ic.index_column_id;
Практический пример, как можно сделать правило коллекции медленным и быстрым способом.
Представим, что мы ищем машины с Microsoft Office Professional Plus 2013, и решили использовать представление v_gs_installed_software. В этом представлении есть два поля с названием ПО, одно из которых индексировано, другое – нет.
Медленный запрос, длящийся 100 секунд:
select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_INSTALLED_SOFTWARE on SMS_G_System_INSTALLED_SOFTWARE.ResourceId = SMS_R_System.ResourceId where SMS_G_System_INSTALLED_SOFTWARE.ARPDisplayName = "Microsoft Office Professional Plus 2013"
Быстрый запрос на 6 секунд:
select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_INSTALLED_SOFTWARE on SMS_G_System_INSTALLED_SOFTWARE.ResourceId = SMS_R_System.ResourceId where SMS_G_System_INSTALLED_SOFTWARE.ProductName = "Microsoft Office Professional Plus 2013"
Таким образом, найдя поле с индексом, мы ускорили время обработки коллекции в 15 раз. Попробуйте посмотреть теперь, что можно сделать с вашими коллекциями?
Найдите коллекции с неоптимальными запросами. Как это сделать?
(select vc.SiteID as [CollID],
vc.CollectionName, 'Not_Like' as Category, s.SQL
from v_Collections vc
inner join Collection_Rules_SQL s
on vc.CollectionID=s.CollectionID
where
s.SQL like '%not like%')
UNION
(select vc.SiteID as [CollID],
vc.CollectionName,
'Not_Equal'
as CAT,
s.SQL
from v_Collections vc
inner join Collection_Rules_SQL s
on vc.CollectionID=s.CollectionID
where s.SQL like '%<>%')
В случае “тяжелых” запросов, переносите нагрузку на клиентов, используя Compliance Settings.
Сделайте Configuration Baseline с набором CI, содержащими сложные вычислениямя, например, “если IP компьютера такой-то, и он содержит такой-то файл, при этом у него есть такая-то служба и запись в реестре, то он будет соответствовать этому базовому шаблону”. Стройте коллекции уже на основе бинарного признака Compliant = Yes/No относительно этого шаблона, и коллекции будут выполняться моментально. Ещё раз отметим, что не стоит включать такие коллекции для инкрементального обновления – таблицы, связанные с CI, не содержат триггеров механизма инкрементальных обновлений. Вам придется полагаться на полное расписание для обновления членства. Тем не менее, подсчет соответствующих или нет машин должен происходить быстро, и на загружать сервер.
Устранение проблем с работой коллекций
Обычно проблемы с коллекциями начинают выражаться в том, что множество колекций в консоли повисает с “песочными часами”. Правила создаются, но ресурсы в коллекции не попадают. Либо коллекций слишком много и они слишком часто обновляются, либо существует одна или несколько коллекций с неудачными правилами-запросами.
Поиск и устранение проблем с производительностью можно свести к одному алгоритму:
- Проверьте межсайтовую репликацию, если у вас есть CAS. Если один из сайтов испытывает проблемы с SQL или связью с иерархией, коллекции на CAS могут прекратить обновляться, пока проблема не будет устранена.
- Проверьте нагрузку на серверы SQL всех первичных сайтов, прежде всего по процессорам, записи на диск с БД, памятью. Если серверы с трудом справляются с нагрузкой, коллекции будут работать медленно.
- Почитайте логи <ConfigMgr>Logscolleval.log и статусные сообщения нашего компонента в консоли (Monitoring > System Status > Component Status > SMS_COLLECTION_EVALUATOR) на наиболее занятых первичных сайтах, можно начать с одного. Есть ли в логах ошибки в работе с SQL сервером? Проблемы со связью, записью в таблицы? Идёт ли работа в colleval.log? Если ошибки с SQL есть, необходимо устранить их, дело не в коллекциях. Установите фильтр cmtrace.exe (вы же ей открывали colleval.log?) на слово seconds. Вы увидите в реальном времени, сколько секунд уходит на обработку правил. Если нормальная работа в colleval.log видна, переходите к следующему пункту. Помните, что все потоки Colleval пишут в этот лог, и если один из них застрял на определенной коллекции, лог все равно не встанет колом, а будет обновляться и дальше от других потоков. Обновляющийся лог это не показатель безпроблемной работы коллекций.Обратите внимание, что сообщения в логе “Failed to manage all files in inbox. Will retry on next processing cycle” не являются проблемой и не мешают работе системы – это косметический дефект, возникающий когда коллекцию создали и быстро удалили, а файлы-триггеры в инбоксе остались. Старые файлы можно удалить вручную, это не навредит.В случае необходимости, можно увеличить максимальный размер файла лога, и включить SQL логирование через реестр на сервере сайта.
- Запустите CEViewer на одном или нескольких первичных сайтах. Предпочтение отдайте тому сайту, где больше всего клиентов, либо у которого самый медленный SQL – там запросы идут наиболее тяжело. Оцените общую ситуацию. Закладка All Queues даст представление о том, насколько быстро обновлятся коллекции, какова очередь, что вообще происходит. Что происходит в Running Evaluations? Двигается ли очередь?Зайдите во вкладки с разными видами очередей (это потоки, которые описаны в этой статье выше) и проверьте время обновления коллекций в секундах. Если у вас есть коллекции, обновляющиеся больше 60-100 секунд, это повод крепко задуматься над их оптимизацией. Есть вероятность, что ваши коллекции “висят” из-за того, что накопилась критическая масса долго выполняющихся правил. Если это так, посмотрите раздел “Рекомендации по построению коллекций”, и попробуйте оптимизировать свои правила. Если проблема возникла внезапно и раньше задержек не было, скорее всего кто-то создал долго выполняющийся запрос, который мы сможем выявить в следующем шаге.
- Откройте SQL Management Studio и выполните на SQL первичного сайта запрос, который покажет процессы SMS_COLLECTION_EVALUATOR, работающие или приостановленные прямо сейчас:
SELECT sess.program_name,
sqltext.TEXT,
req.session_id,
req.status,
req.command,
req.cpu_time,
req.total_elapsed_time
FROM sys.dm_exec_requests req
Left join sys.dm_exec_sessions sess on sess.session_id = req.session_id
CROSS APPLY sys.dm_exec_sql_text(sql_handle) AS sqltext
WHERE sess.program_name like 'SMS_COLLECTION%'
ORDER BY req.total_elapsed_time DESC
Запросы выводятся в порядке времени выполнения (поле total_elapsed_time). В поле SQLText мы видем текст этих запросов. Один из них, вероятно, является “тяжелым” запросом из вашей коллекции. Может так случиться, что этот запрос никогда не завершается, поэтому в предыдущем шаге, в CEViewer вы его времени выполнения никогда не увидете. Именно этот случай произошел в начале статьи. Если запрос какой-то коллекции выполняется весьма долго, то в colleval.log вы этого также можете не увидеть. Лог будет бежать дальше, так как другие коллекции в других потоках будут считаться нормально. Например, инкрементальное обновление коллекций будет работать, в то время как обсчет новых коллекций будет введен в ступор вашим запросом.
Посмотрите текст запроса в поле TEXT, найдите в нём откуда идет выборка данных (после оператора FROM).
Скопируйте названия этих таблиц или небольшой кусок запроса вокруг них, выполните новый запрос, чтобы найти проблемную коллекцию
select * from v_Collections
where CollectionID in
(select CollectionID from collection_rules where collectionID in
(select collectionid from collection_rules_sql
where sql like‘%ЧАСТЬ ТЕКСТА ПРОБЛЕМНОГО ЗАПРОСА%’
))
В результате вы найдете проблемную коллекцию, и сможете приступить к её оптимизации. Если этот конкретный запрос прямо сейчас в статусе Running в списке задач –
Зайдите на сервер SQL и проверьте размер файлов TempDB, tempdb.log. Растут ли эти файлы прямо сейчас? Если рост некотролируемо продолжается, попробуйте изменить запрос коллекции на тот, что будет работать нормально, или просто удалив неудачное правило.Затем на ваших SQL серверах в SQL Management Studio зайдите в Activity Monitor (прав. кнопка мыши на сервер, Activity Monitor), далее Processes, и завершите процесс от SMS_COLECTION_EVALUATOR с вашим неудачным запросом.
Вот, собственно, и всё, что я пока могу рассказать вам о работе с коллекциями. Если у уважаемых читателей есть какие-то дополнения или комментарии, мы будем рады их прочитать!
