Существенное снижение производительности после перехода на AX 2009 с Axapta 3.0

[Rivez]

Цитата:

Сообщение от savel

А по моему - загрузка процессора AOS'а как раз и показывает нормальную рабочую загрузку. Т.е. это показатель, что процессорной мощности AOS'а хватает для текущих задач. Если средняя загрузка будет выше 30 - первый признак того что мощность нужно повышать. Выше 50 - повышать без раздумий.

согласен, но почему-то операции выполняются долго в системе, причем периодически

[Logger]

Если я правильно понимаю, gl00mie имел в виду загрузку файл сервера, на котором хранится приложение. Этот сервер не обязательно совпадает с одним из аосов. Это может быть выделенный сервак - единственная задача которого расшаривать для аосов файлы приложения по сети.

[Ivanhoe]

А у вас клиенты стоят на рабочих местах или на терминале? Нет ли заметного торможения самого сервера (СУБД / AOS), а не конкретно AX?

[Rivez]

Цитата:

Сообщение от Ivanhoe

А у вас клиенты стоят на рабочих местах или на терминале?

Часть клиентов(70-80 пользователей) работает через терминал, на котором не стоит AOS. Остальная часть (100-120 пользователей) на рабочих местах.

Цитата:

Сообщение от Ivanhoe

Нет ли заметного торможения самого сервера (СУБД / AOS), а не конкретно AX?

вопрос не понятен

[Rivez]

up

[Андрей К.]

Цитата:

Сообщение от Rivez

вопрос не понятен

имеется в виду тормозит ли скл сервер без связки к аксапте, то есть сам по себе (ну например под искусственной нагрузкой тяжелыми запросами через менеджмент студию)

[Wamr]

еще идеи
посмотрите, где лежит tempdb - стала сильнонагруженной базой и должна быть на быстрых дисках
проверьте периодические процедуры когда и как выполняются на SQL сервере, например обновление кубов, бекапы и т.п.
посмотрите как себя чувствуют соседние сервера (PDC, файл-сервера и бекап-сервера), как там с загрузкой и торможением.

попробуйте все-таки понять кто тормозит АОС SQL или сеть

[gl00mie]

По-моему, коллективное угадывание зашло в тупик - пора браться за performance monitor и выяснять на месте, чем таким специфичным сопровождается возникновение тормозов.

[BOAL]

Подниму тему, пока просто с идеями (без ответов, их проверим только вечером)

Обнаружили проблему с производительностью отчета, стали копать.
на рабочем сервере (2 проца по 4 ядра с НТ, то есть 16 потоков) и на виртуальной разработке (на обычном ПК (двух ядерный Коре 2 дуо) , в виртуалке 1 проц показан
Отчет строится одинаковое время по одним данным (на бакапе БД) - чего по идее быть не должно.

Стали копать.
Монитор работы ДЕВ (виртуалка 1 проц) показывал 100% занятости проца АОСом
Монитор работы ВРК (16 потоков) показывал 6% занятости (что равно как раз 1/16, и оч подозрительно)
В настройках конфигурации сервера стоит на закладке Перфоманс По умолчанию для ядер проца.
Выбрал определенные (10 шт процов из 16 для тестов), но пока АОС не можем перестартить, чтоб проверить

Кто сталкивался с похожим?
Или может протестить сам, не дожидаясь вечера.

Речь о AX2009 RU 6

[Wamr]

а в чем вопрос-то... почему один отчет выполняется в один поток на одном ядрышке?

[BOAL]

Цитата:

Сообщение от Wamr

а в чем вопрос-то... почему один отчет выполняется в один поток на одном ядрышке?

Вопрос (и подозрение), что отметка "по умолчанию" для АОС в настройках работает как выбор 1 ядра, а не всех. То есть нужно всегда указать нужные (или все) ядра ручками.

[Михаил Андреев]

А как настроен сервер MS SQL? В частности, tempdb?
MS рекомендует для каждого ядра отделный файл tempdb делать: http://msdn.microsoft.com/ru-ru/library/ms175527.aspx
Но не факт, что это сможет помочь на примере только одного отчета - может так оказаться, что там просто нечего распараллеливать, тогда как ни крути, а ускорения не будет.

[fed]

Цитата:

Сообщение от Михаил Андреев

А как настроен сервер MS SQL? В частности, tempdb?
MS рекомендует для каждого ядра отделный файл tempdb делать: http://msdn.microsoft.com/ru-ru/library/ms175527.aspx
Но не факт, что это сможет помочь на примере только одного отчета - может так оказаться, что там просто нечего распараллеливать, тогда как ни крути, а ускорения не будет.

Я всегда считал, что AOS в принципе не умеет сам ничего распараллеливать внутри одной пользовательской сессии. Единственный способ что-то распараллелить, это написать хитрый джоб, который порождает runtime-задачи. Если BOAL такой подход использует, то да - есть повод подумать. Если не использует, я никак не могу представить чтобы боевой AOS сам распараллелил отчет на 16 ядер... Скорее всего он просто одно ядро занимает, а task manager тупо показывает это как 1/16*100% утилизации - 6%

[BOAL]

Цитата:

task manager тупо показывает это как 1/16*100% утилизации - 6%

Именно так, тк смотрели мониторингом, занято именно 1 ядро на 100%

Проверили запуск этих отчетов с двух пользователей.
Теперь на 100% занято и второе ядро и общие 12%

Да, теперь все понятно.
Значит "По умолчанию" на закладке производительность - это все же все ядра скорее всего

Интересно, как себя поведет система, если вся ядра кончатся?
Но имхо все это оч печально - вместо использования простаивающих 15 ядер, работает одно
И прироста скорости от мегасервера вообще нет для конкретно работы 1 пользователя
Что на обычном ПК ставить АХ, что на сервере - эффект только за счет ускорения в SQL видать

[Bega]

Обратите внимание на флаг is_read_committed_snapshot_on для базы DAX2009, у нас только после установки его в значение 1 исчезли проблемы с блокировками.

http://blogs.msdn.com/b/axsupport/ar...namics-ax.aspx