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

[Logger]

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

[Rivez]

Цитата:

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

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

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

[Ivanhoe]

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

[Rivez]

Цитата:

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

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

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

Цитата:

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

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

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

[Rivez]

up

[Wamr]

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

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

[gl00mie]

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

[Андрей К.]

Цитата:

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

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

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

[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 видать

[fed]

Цитата:

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

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

Ну то есть то что вы ухитрились одно ядро на 100% занять - это немножко странно конечно (обычно процесс какое-то время отклика от сиквела ждет). Но сравнение утилизации с боевым AOS - это явно мимо кассы.

Кстати - безумные цифры утилизации я видел тогда, когда кто-то включал full table cache на какую-то часто обновляемую большую таблицу. В итоге AOS ее на каждый чих перечитывал с сиквела и разноски простого складского журнала из 40 строк хватало для создания 70% утилизации AOS (с одним ядром процессорным). Двух журналов - для 100% утилизации. Может это ваш случай ?

[BOAL]

Там оч много запросов, отчет только на чтение.
Но, если поведение, что 1 чел всегда занимает 1 поток верна, то получается, что масштабирования увеличением железкой (сервера) не добиться. Так что ли?
А как за пакетные операции, оно тоже будут 1 процессор занимать?
Вместо работы операции ночной за 10 мин, будет 3часа... оч печально

Получается, что для АОС АХ нужно брать какой-нть высокочастотный проц АМД без НТ, которое в данном случае вообще зло (делит процессор пополам).

Все это пока домыслы по мотивам приведенного выше.

===
некая мысля как такое (если это вообще реально так) обойти:
нужно АОС ставить всегда в вируталке, давать ей 1-2 проца (чтоб она думала, что у нее 1-2 проца), но на деле считать вируталку всей мощью серва
Тогда этот 1 проц будет 8 ядер, что и ожидается
То есть обмануть неумеющий пользовать всю мощь АОС через другой софт

[fed]

Цитата:

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

Там оч много запросов, отчет только на чтение.
Но, если поведение, что 1 чел всегда занимает 1 поток верна, то получается, что масштабирования увеличением железкой (сервера) не добиться. Так что ли?
А как за пакетные операции, оно тоже будут 1 процессор занимать?
Вместо работы операции ночной за 10 мин, будет 3часа... оч печально

Получается, что для АОС АХ нужно брать какой-нть высокочастотный проц АМД без НТ, которое в данном случае вообще зло (делит процессор пополам).

Все это пока домыслы по мотивам приведенного выше.

Посмотри на то как вот этот вот отчет написан: axinthefield: Reconciling Inventory to GL in Dynamics AX
Они там порождают кучу хелперов на батч-сервере как раз для того чтобы запросы с многих ядер кидать. Я сам как-то написал мегазадачу для распределения себестоимости продаж по ABC. У меня основная задача порождала кучу хелперов, с зависимостями между ними. Батч сервер их там сам распараллеливал между ядрами (параллельных хелперов было больше чем ядер) и сам запускал новые задачи после того как те задачи, от которых они зависели, завершались. В итоге - миллион с копейками записей с распределениями (не в ГК, просто в отдельную таблицу для анализа), на батч-сервере с 4 ядрами создаются за полчаса в среднем (Это еще включая рассчет промежуточных таблиц с базами для распределения).
Так что механизм крайне полезный и могучий, надо просто большие отчеты и задачи заранее проектировать с идеей что они будут на батч-сервере во многих параллельных задачах исполняться.

P.S. Что-то мне кажется что идея эммулировать один мощный проц из множества ядер путем виртуализации не сработает. Если бы это было возможно, Intel бы давно делал одноядерные (с виду) процессора, внутри состоящие из кучи RISC-ядер. Они ведь и пошли по пути увеличения числа ядер, только потому что увеличивать производительность одного ядра не смогли...

[Bega]

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

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

[gl00mie]

Цитата:

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

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

Чтобы это проверить, достаточно пойти в диспетчер задач, найти процесс AOS'а, выбрать Set Affinity и посмотреть, что там нарисуется.

Цитата:

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

Интересно, как себя поведет система, если вся ядра кончатся?

У планировщика времени проца в ядре ОСи постоянно "заканчиваются ядра"

Цитата:

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

Но, если поведение, что 1 чел всегда занимает 1 поток верна, то получается, что масштабирования увеличением железкой (сервера) не добиться. Так что ли?

По-моему, масштабируемость - это способность сохранять некий уровень производительности при пропорциональном увеличении нагрузки. Если одна сессия обслуживается на 1-ядерном проце и на 16-ядерном (скажем, с той же тактовой частотой), то тут производительности расти особо неотчего, а вот если при тех же условиях запустить 16 таких сессий на 1-ядерном и 16-ядерном процах, вот тогда проявится эффект масштабируемости системы.

[BOAL]

Спасибо всем за объяснения, покопал, поразбирался - теперь больше в теме.
На деле смутил стереотип, что со времен ах 2.5-3.0 тесты на локале (ноуте, ПК) проходили сильно медленнее, чем на боевом серве.
Но теперь бытовые ноуты имею процы тех самых серверов и в однопользовательском режиме работают быстрее (парадокс, который и вызвал непонимание), чем на боевом дорогущем сервере.
Так как в один поток серверное одно ядро вполне сопоставимо (а то и ниже по частоте) проца бытового ПК.

Масштабирование предполагалось же не только от увеличения числа пользователей, но и числа данных.
Раньше это прокатывало, тк сервера становились мощнее (частоты и кэш одного ядра). Теперь прогресс встал колом - увеличивают ядра.
Если в БД что-то долгое считается 1 час, то когда данных будет х2, будет условно считать 2ч. И железкой это не лечится, тк ничего не даст.
Нужно предварительно переписать логику на многопоточность.
Ну или в данной ситуации проблема так остро (в х2 раза) не встанет из-за более умного SQLа, который заюзает ядра все подряд, даже на 1 селект (надеюсь это так?).

Но очень забавно, когда заявленная поддержка многопоточности и масштабируемости в АХ осуществляется в ручном режиме на уровне указания запуска конкретных методов внутри одного кода в разные потоки.
Это, конечно, автоматизация в действии, и высокоинтеллектуальная система потоков на АОС, ага
Так что, я пока не выкинул идею поизучать методы "обмана" АОС через сторонний софт.

Вот скажите мне, кто в теме, модные облачные вычисления будет так же работать?
Будет, скажем, в облаке древний 386 проц и он выпадет кому-то в помощь как один поток или как часть потока совместно с другими процами? За счет чего будет работать облако, за счет софта оболочки (облока) или спецом написанных програм для работы в этом облаке?
Так как АХ2009 при таком АОС в облаке запускать категорически нельзя, если ему хаотично будет выбираться одно ядно произвольного (по мощности) проца.
Есть же куча старого софта который не знает о многоядерности. И внутри ОС Виндовс этот софт занимает все ядра по 100%, а если в диспетчере выделить только одно, то сразу видны тормоза. Значит как это это работает и без переписывания на потоки, может не столь эффективно, как заложенное в коде деление, но работает.
Соотв. по идее нужно аналогично дать АОСу виртуальные ядра, из кучи реальных, что и даст требуемый прирос именно аппаратно, а без тюнинга кода.