Некоторые из этих проблем могут показаться Вам тривиальными, но несмотря на обилие информации по Dynamics AX, они встречаются довольно часто, особенно при использовании настроек по умолчанию. Обратите внимание на то, что нумерация в дальнейшем списке условна и не отражает степень важности той или иной проблемы.
1. Max Degree of Parallelism не установлен в значение 1
Настройка по умолчанию при установке SQL-сервера равна нулю. Если приложения OLAP работают на том же сервере SQL, есть риск, что используются все процессоры (% времени процессора). Это в свою очередь, влияет на производительность OLTP-приложения. Чтобы избежать этого, рекомендуется установить MAXDOP в значение 1. Обратите внимание, что случаются ситуации, когда выполняются запросы или пакетная обработка данных на SQL-сервере, и тогда использование параллельной обработки запросов может быть полезным. В этом случае значения Max Degree of Parallelism от 2 до 4, скорее всего, будет лучшим значением с учетом обоих типов запросов.
2. Не использование Pre-Allocation для не непрерывных номерных серий при высокой загрузке
Это очень важная настройка приложения Dynamics AX, которую следует пересматривать на рабочем сервере каждые несколько месяцев в соответствии с использованием номерных серий. В основном номерные серии могут быть непрерывными (Continuous) или не являться таковыми (Non Continuous). Когда они не являются непрерывными, можно разрешить предварительное распределение номеров и, следовательно, уменьшить число обращений к базе данных и повысить производительность. Когда потребление высокое, например, несколько номеров в секунду, мы заметили события Lock Escalation в таблице NumberSequenceTable. Это особенно актуально, когда выполняется пакетная обработка Dynamics AX, создающая тысячи записей в строках журналов или при выставлении накладных в заказах на продажу. Чтобы лучше оценить такое потребление, прочтите пост в блоге.
3. Недостаточное автоматическое увеличение для файлов данных и лог-файлов
По умолчанию автоматическое увеличение файлов данных составляет 1 Мб, а лог-файлов — на 10 %. Если начальный размер слишком мал, вы заметите частые события автоматического увеличения, что отрицательно влияет на производительность. В SQL-трассировке можно контролировать такие события и наблюдать продолжительность каждого автоматического увеличения. Цель — настроить параметры автоматического увеличения файлов данных и логов Dynamics AX и TempDB, чтобы предотвратить частые события автоматического увеличения в дневное время. Вы можете следить за такими событиями и их продолжительностью в миллисекундах при помощи SQL-трассировки с ID 92 и 93. Можно порекомендовать установить автоматическое увеличение на более высокое значение, увеличив его с 200 Мб до 500 Мб.
4. Узкое место процессора пакетной обработки Dynamics AX
Большинство клиентов, работающих на Dynamics AX, задействуют только один экземпляр AOS для пакетной обработки и несколько AOS для нагрузки толстых клиентов, что, следовательно, ограничивает число пакетных потоков количеством логических процессоров, доступных на данном AOS. Кроме того, установка пакетов на AOS часто по умолчанию равна максимум 8 пакетным потокам и 24 часам в сутки. Для расчета количества потоков нужно умножить количество ядер на 2, но это зависит от запущенных процессов и должно быть подтверждено в ходе тестировании. Чтобы преодолеть это ограничение, вы можете установить разные потоки пакетов для разного времени суток и включить больше серверов приложений для пакетной обработки в ночное время. Например, вы можете выделить один сервер приложений для нагрузки толстых клиентов с 8 утра до 6 вечера и оптимизировать его для пакетной обработки в ночное время. В блоге можно прочитать о том, как научиться настраивать количество потоков, необходимое для более быстрого пакетного выполнения.
5. Ведение журнала базы данных для больших приложений
Это еще одна важная настройка приложения Dynamics AX, которая часто оказывает негативное влияние при чрезмерном использовании. Эта функция позволяет отслеживать все операции в любом поле любой таблицы базы данных (вставка/обновление/удаление записи и переименование первичного ключа). Эта информация будет храниться в таблице SYSDATABASELOG. Не следует использовать это свойство для автоматического выполнения транзакций, выполняемых в пакетном режиме. Вы можете следить за ростом таблицы SYSDATABASELOG и оценить самый нагружающий вариант настройки при помощи журнала базы данных. Отметим, что включение ведения журнала в поле, например, CreatedDateTime или ModifiedDateTime изменит поведение по умолчанию InsertRecordSet с одного обращения к базе данных с полным обходом (a single round trip) на работу с каждой записью по отдельности (a record-by-record operation). Есть три рекомендации:
● Определите политику сохранения данных — сохранять данные только за последние 3 месяца, чтобы размер таблицы SYSDATABASELOG оставался небольшим. Форму очистки можно найти в Администрирование | Запросы | Журнал базы данных | Журнал очистки.
● Избегайте усиленного журналирования транзакционных таблиц, которые используются при выполнении пакетных заданий, и повысьте приоритет задач, которые абсолютно необходимы для удовлетворения требований бизнеса.
● Избегайте журналирования значений CreatedDateTime или ModifiedDateTime в любой таблице.
6. Отсутствие кластерных индексов
Может, это и не самая распространенная проблема, но определенно, одна из наиболее оказывающих влияние на работу. Все таблицы в базе данных OLTP должны иметь кластерные индексы, и их необходимо исследовать, глядя на таблицы с высокой активностью, или таблицы, которые часто бывают в ситуациях блокировки или взаимоблокировки, таблицы с частыми непроизводительными задержками передаваемых строк. Поскольку модель базы данных меняется в процессе жизненного цикла приложения после новых модификаций, а индексы управляются из дерева объектов приложения, важно периодически проверять отсутствующие индексы по статистике SQL-сервера.
Для обнаружения всех отсутствующих индексов можно использовать запрос “4-Analyze_SQL_Indexes.sql” из Dynamicsperf версии 1.1.6.
7. Неправильное ведение индексов
В дополнение к упомянутой выше проблеме отсутствия кластерных индексов, ведение индексов является одним из самых проблемных вопросов Dynamics AX. При плохом ведении индексов или неведении индексов вообще, наступят те же последствия: при устаревании статистики, Query Plan будет использовать операцию SCAN (сканирование) вместо операции SEEK (поиск), и их производительность сильно ухудшится. Уровень фрагментации не столь критичен для производительности, но он также должен быть частью еженедельного обслуживания. Ниже приведен рекомендованный пример:
● Реорганизуйте индексы с количеством страниц более 1000 и фрагментированные от 10 % до 30 %.
● Перестройте индексы с количеством страниц более 1000 и фрагментированные более чем на 30 %, используя коэффициенты заполнения от 85 % до 95 % в зависимости от частоты выполнения задания.
Кроме того, настоятельно рекомендуется регулярно запускать Update Statistics (обновление статистики) в режиме FULL SCAN (полная проверка) или, по крайней мере, в режиме «50 % sample», а также с включенными опциями Auto_Create_Stats и Auto_Update_Stats. Если вы используете SQL 2008 R2 SP1 или выше, вы также можете включить Trace Flag 2371.
8. Включение отладчика на рабочем сервере
В Dynamics AX Server Configuration Utility необходимо всегда отключать две настройки, которые разрешают пользовательские контрольные точки останова и глобальные точки останова для отладки кода X++.
Даже если вы удалите все точки останова в дереве объектов приложения (АОТ)), вы всё равно будете испытывать снижение производительности примерно на 10 %.
9. Управление питанием установлено в значание “Сбалансированное”
Это просто, но почти никогда не используется на рабочем приложении, так как управление питанием по умолчанию установлено сбалансированным. Переключение на высокую производительность настоятельно рекомендуется для всех Windows Server 2008, используемых в рабочих приложениях. Эта настройка находится на Панели управления — Оборудование — Параметры питания или с помощью следующей команды: powercfg — getactivescheme.
10. Ядро и приложения устарели, и их необходимо обновить
Наконец, что не менее важно, обновляйте свои решения Dynamics AX как можно чаще. Например, вы можете заметить, что последняя ваша версия для Dynamics AX 2009 SP1 — RU8, и ей уже один год. За это время было выпущено несколько сотен оперативных исправлений, и их лучше применить для использования последних исправлений от группы разработчиков продукта. Ниже приведены две рекомендации:
● Корректируйте исполняемые файлы при помощи последней доступной версии ядра. Можно увидеть последние KB в блоге поддержки AX. На сегодняшний день последняя версия для Dynamics AX 2009 SP1 — 5.0.1600.1824 от июня 2013 года.
● Приложение необходимо обновить до последней имеющейся версии RU, но вы также можете проверять список отдельных оперативных исправлений, относящихся к вашему отраслевому решению.
Понятно, что этот список не исчерпывающий, и мы могли бы придумать сотни вопросов в отношении существующих копий Dynamics AX, но я надеюсь, это поможет вам справиться с некоторыми текущими проблемами. Также рекомендую познакомиться с большой статьей Арвинда Шуамсундара (Arvind Shyamsundar) в блоге MSPFE о 10 наиболее важных проблемах SQL-серверов в программе оценки рисков SQL-серверов.
Наконец, если у вас есть проблемы с производительностью – обратитесь к специалистам
Оригинал статьи: “Top 10 issues discovered from Dynamics AX Health Check” на MSDN Blogs
Добавить комментарий
Для отправки комментария вам необходимо авторизоваться.