Администрирование
27
Мар
2

CRM Asynchronous Service

CRM Asynchronous Service это win-служба, которая выполняет продолжительные операции, независимые от основных базовых операций CRM. По сути это управляемая очередь, используемая для выполнения таких вещей как Бизнес-процессы, асинхронные плагины и другие операции массовый импорт и обнаружение дубликатов. Эта очередь хранится в таблице AsyncOperationBase. В CRM за данную таблицу отвечает объест Системные задания. Все записи представленные в нем имеют свои тип:

ObjectTypeCode ObjectTypCode Name
1 System Event
2 Bulk Email
3 Import File Parse
4 Transform Parse Data
5 Import
6 Activity Propagation
7 Duplicate Detection Rule Publish
8 Bulk Duplicate Detection
9 SQM Data Collection
10 Workflow
11 Quick Campaign
12 Matchcode Update
13 Bulk Delete
14 Deletion Service
15 Index Management
16 Collect Organization Statistics
17 Import Subprocess
18 Calculate Organization Storage Size
19 Collect Organization Database Statistics
20 Collection Organization Size Statistics
21 Database Tuning
22 Calculate Organization Maximum Storage Size
23 Bulk Delete Subprocess
24 Update Statistic Intervals
25 Organization Full Text Catalog Index
26 Database log backup
27 Update Contract States
28 DBCC SHRINKDATABASE maintenance job
29 DBCC SHRINKFILE maintenance job
30 Reindex all indices maintenance job
31 Storage Limit Notification
32 Cleanup inactive workflow assemblies
35 Recurring Series Expansion
38 Import Sample Data
40 Goal Roll Up
41 Audit Partition Creation
42 Check For Language Pack Updates
43 Provision Language Pack
44 Update Organization Database
45 Update Solution
46 Regenerate Entity Row Count Snapshot Data
47 Regenerate Read Share Snapshot Data
50 Outgoing Activity
51 Incoming Email Processing
52 Mailbox Test Access
53 Encryption Health Check
54 Execute Async Request
49 Post to Yammer
56 Update Entitlement States

Диагностика

Для поддержания высокой производительности лучше, чтобы в этой таблице было меньше миллиона записей. Чтобы увидеть полный размер таблицы AsyncOperationBase выполинте следующий запрос:

SELECT
	SCH.name AS [SchemaName],
	SO.name AS [TableName],
	UT.RecordCount AS [RowCount],
	UT.ReservedPageCount* 8 / 1024 AS [Reserved_MB],
	UT.Data * 8 / 1024 AS [Data_MB],
	CASE WHEN UT.used > UT.data THEN UT.used - UT.data ELSE 0 END * 8 / 1024 AS [IndexSize_MB],
	CASE WHEN UT.ReservedPageCount > UT.used THEN UT.ReservedPageCount - UT.used ELSE 0 END * 8 / 1024 AS [Unused_MB]
FROM (
	SELECT
		PS.object_id,
		SUM(CASE WHEN PS.index_id < 2 THEN row_count ELSE 0 END) AS [RecordCount],
		SUM(PS.reserved_page_count) AS [ReservedPageCount],
		SUM(CASE WHEN PS.index_id < 2 THEN PS.in_row_data_page_count + PS.lob_used_page_count + PS.row_overflow_used_page_count ELSE PS.lob_used_page_count + PS.row_overflow_used_page_count END) AS [Data],
		SUM(PS.used_page_count) AS used
	FROM
		sys.dm_db_partition_stats PS
	GROUP BY
		PS.object_id
	) AS UT
	INNER JOIN sys.all_objects SO ON UT.object_id = SO.object_id
	INNER JOIN sys.schemas SCH ON SO.schema_id = SCH.schema_id
WHERE
	SO.type <> 'S' and SO.type <> 'IT'   
ORDER BY
	SO.name

Если количество записей больше миллиона, то асинхронная служба CRM может начать сбоить. Чтобы определить какой тип асинхронных заданий задержался в таблице выполните следующий запрос:

SELECT
	OperationType,
	StatusCode,
	StateCode,
	COUNT(*) AS [RecordCount]
FROM
	AsyncOperationBase 
GROUP BY
	OperationType,
	StatusCode,
	StateCode

А чтобы идентифицировать на каком временном промежутки больше всего не выполненных заданий, запустите такой SQL-запрос:

SELECT
	Name,
	DATEPART(YEAR,CreatedOn) AS [Year],
	DATEPART(MONTH,CreatedOn) AS [Month],
	OperationType,
	StatusCode,
	StateCode,
	Count(*) AS [RecordCount] 
FROM
	AsyncOperationBase
WHERE
	StartedOn IS NOT NULL
GROUP BY
	Name,
	DATEPART(YEAR,CreatedOn),
	DATEPART(MONTH,CreatedOn),
	OperationType,
	StatusCode,
	StateCode

Локализовав более точно проблему, Вы можете воспользоваться Расширенным поиском, чтобы найти проблемные Системные задания в состоянии ожидания или ошибки. Открыв экземпляры таких заданий Вы сможете ознакомится с подробным описанием ошибки.

Настройки

DeploymentProperties

CRM имеет ряд системных настроек, которые влияют на работу асинхронной службы. Эти настройки находятся в базе данных MSCRM_CONFIG в таблице DeploymentProperties:

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

    • Значение по умолчанию: 2000
    • Рекомендованное значение: Рекомендуемое значение для этой установки зависят от Вашей среды: для односерверного развертывания с 8 (и менее) Гбайт RAM установка должна быть около 500; для выделенного асинхронного сервера с 8 Гбайт RAM – 2000 не проблема. В остальном зависит от прямой нагрузки вызванной асинхронным сервисом.
  • AsyncItemsInMemoryLow
    Определяет минимальное количество асинхронных элементов, которые асинхронная служба будет держать в памяти.

    • Значение по умолчанию: 1000
    • Рекомендованное значение: Рекомендуемое значение, также как и для максимальной настройки, зависит от Вашей среды: для односерверного развертывания с 8 (и менее) Гбайт RAM установка должна быть около 250; для выделенного асинхронного сервера с 8 Гбайт RAM – 2000. В остальном смотрите по ситуации и нагрузки вызванной асинхронным сервисом.
  • AsyncStateStatusUpdateInterval
    Определяет, как часто (в секундах) обновляются записи асинхронных операций после обработки асинхронным сервисом.

    • Значение по умолчанию: 5
    • Рекомендованное значение: 5
      Это значение должно подбираться с учетом параметра AsyncSelectInterval.
  • AsyncMaximumThreadsPerCPU
    Определяет количество потоков, доступных асинхронной службе.

    • Значение по умолчанию: 5
    • Рекомендованное значение: зависит от количества процессоров на сервере, на котором установлена асинхронная служба. Для эффективной работы это значение должно совпадать с количеством процессоров.
  • AsyncSelectInterval
    Количество секунд между запросами к таблице AsyncOperationBase, для забора следующей порции данных. Каждый раз, когда наступает этот интервал, система определяет сколько элементов сейчас находится в памяти. Если меньше чем определено в AsyncItemsInMemoryLow, то асинхронная служба вытянет (посредством запроса в веб-сервис CRM) следующую порцию чтобы достичь значения AsyncItemsInMemoryHigh.

    • Значение по умолчанию: 5
    • Рекомендованное значение: 5
  • AsyncSelectParallelism
    Определяет сколько процессоров выделяется под запрос. С т.з. SQL сервера эта настройка позволяет асинхронной службе выполнять запросы с max degree of parallelism (MAXDOP) больше чем 1. Применимо только для SQL Server Enterprise.

    • Значение по умолчанию: 5
  • AsyncThrottlingConfiguration
    Распределяет рабочую нагрузку между различными асинхронными работами, таких как БП (workflow), массовая рассылка по электронной почте (bulk e-mail), импорт (import), разбор импортируемых файлов (parse), преобразования (transform).
    Пример настройки посредством PowerShell:

    Add-PSSnapin Microsoft.Crm.PowerShell
    $AsyncSetting=Get-CrmSetting -SettingType AsyncSettings
    $AsyncSetting.ThrottlingConfiguration="Workflow=25;Import=20;Parse=20;Transform=20"
    Set-CrmSetting -Setting $AsyncSettings
    

    Значение по умолчанию не определено.

Реестр

Допустим у Вас имеется 2 асинхронных сервера, которые одновременно опрашивают веб-сервис в поисках новых заданий. В таком может получиться ситуация, когда они попытаются в одно и то же время обработать одно и то же задание, что вызовет блокировку в БД (или может привести к двойному выполнению работы).

Чтобы избежать этого в реестре на асинхронных серверах, по пути HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSCRM, создайте DWORD-ключ AsyncDBAppLock со значением 1.

Config

Веб-сайт CRM, который размещен на сервере с множеством процессоров/ядер, автоматически использует режим Garbage Collection сервера. Но для управляемой .Net программы, такой как CRMAsyncService.exe «сборка мусора» по умолчанию будет задана такая же как на рабочей станции – т.е. одновременно только на одном процессоре/ядре.

В случае тяжелых реализаций асинхронных процессов это может привести к высокой загрузке CPU или заполнению памяти.

Чтобы позволить CRMAsyncService.exe использовать в своих интересах все процессоры/ядра сервера добавьте в конфиг-файл асинхронной службы (C:\Program Files\Microsoft Dynamics CRM\Server\bin\CRMAsyncService.exe.config) следующий параметр и перезапустите асинхронный сервис:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
   <runtime>
      <gcServer enabled="true"/>
   </runtime>
</configuration>

Хардкор

В настройках БП и асинхронных плагинов есть галка, которая позволяет автоматически удалять успешно выполненные Системные задания. Если она у вас не установлена, то таблица AsyncOperationBase может быстро распухнуть и это плохо скажется на работе асинхронного сервиса. Чтобы очистить ее вручную выполните запрос из статьи:

https://support.microsoft.com/en-us/help/968520/performance-is-slow-if-the-asyncoperationbase-table-becomes-too-large-in-microsoft-dynamics-crm

Запрос удаляет только записи со StatusCodes 30, 32 и OperationTypeCodes 1, 9, 10, 12, 25, 27.

Комментарии (2)
  • melhior4eg 27.03.2017

    Не сохранился параметр(((
    «следующий параметр и перезапустите асинхронный сервис:»

  • slivka_83 27.03.2017

    Обновил.

*

code