AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 10.09.2018, 17:02   #1  
Masel is offline
Masel
Участник
 
39 / 527 (18) +++++++
Регистрация: 19.09.2007
AX 2012 - глюки ядра
Добрый день,
Может кто сталкивался с такой проблемой и знает как ее решить (особо не рассчитываю, просто накипело).
Все видно в принципе на трассировке. Невменяемые затраты времени на простейшие методы без вызовов БД:

Конкретно этот пример AX 2012 R2, ядро 6.2.3000.5063. Код в CIL в пакете. В тот же момент проходил пересчет склада в 32 потока. Различные артефакты подобного рода наблюдаю и в других ситуациях, CIL, не CIL, иногда бывают тормоза на методах, которые вызывают strfmt() и больше вообще ничего. Перезагрузка аоса обычно лечит все такие ситуации, в CIL иногда становится лучше и без перезагрузки.
Старый 10.09.2018, 17:35   #2  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,865 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Исчерпывающего ответа у меня нет, но есть наводящие мысли.

1. Вот тут описан глюк трейспарсера когда он неправильно отображал время и указан способ как узнать правильное время между событиями.
Тормозит создание буфера.

2. Если код исполняется в CIL то при вызове функций ядра у нас получается передача управления между управляемым кодом и неуправляемым кодом и на этом идет потеря производительности.
Подробнее тут:
https://blogs.msdn.microsoft.com/mfp...-to-the-metal/

Не уверен, что в вашем случае это было причиной, но про это надо не забывать.

3. В некоторых специфических случаях (при массовой обработке строк) CIL может работать медленнее чем p-code
см:
Помогите найти: Сравнение производительности различных операндов при конкатенации строк

У вас как раз идет работа со строкой.
Старый 10.09.2018, 17:40   #3  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,865 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
В вашем случае вместо QueryValue(parameter) для енума можно попробовать написать просто int2str(parameter)
Результат по идее будет тот же, но надеюсь, что побыстрее сработает.
Старый 10.09.2018, 17:49   #4  
Masel is offline
Masel
Участник
 
39 / 527 (18) +++++++
Регистрация: 19.09.2007
Цитата:
Сообщение от Logger Посмотреть сообщение
В вашем случае вместо QueryValue(parameter) для енума можно попробовать написать просто int2str(parameter)
Результат по идее будет тот же, но надеюсь, что побыстрее сработает.
Написать можно конечно, даже может быть оно поможет конкретно в этом месте. Но таких мест огромное количество, в данном случае это стандартный функционал - резервирование InventSum::newQueryReservation. В общем печаль. О том, что трейспарсер показывает что-то не то, я тоже думал, но функционал реально тормозит и везде при различных сценариях вызова тормозит queryvalue в данной трассировке. Думаю если бы дело было только в трейспарсере то в зависимости от стека вызова, соседних вызовов и т.д. время раскидывалось на разные методы.
Такого рода глюки кстати наблюдал и ранее и не только на этом приложении, не только в этой компании.
Старый 10.09.2018, 18:05   #5  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,865 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Получается что тормозит enum2value()
но метод состоит из нескольких вызов функций ядра.
может посмотреть какая из них тупит ?

Возможно аналогичный вызов и в других местах дает тормоза.
Старый 10.09.2018, 19:49   #6  
DSPIC is offline
DSPIC
Боец
 
1,077 / 1234 (44) ++++++++
Регистрация: 11.04.2008
какая-то кустарщина в enum2value написана, никогда туда не заглядывал. Вдобавок, медленный reflection. Я бы подкэшировал (globalCache) и отпустил с миром.
Старый 10.09.2018, 19:57   #7  
DSPIC is offline
DSPIC
Боец
 
1,077 / 1234 (44) ++++++++
Регистрация: 11.04.2008
ещё одна мысль: strfmt('%1', E) очевидно обращается к Labels, которые можно попробовать переиндексировать (снести *.ali, *.alc).
Старый 11.09.2018, 12:07   #8  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2155 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Наблюдал такое на нескольких инсталляциях.
Основные два вопроса: обслуживаете ли вы БД модели и что у вас в целом с производительностью АОС серверов.

Также часто проблема в сети - какая скорость сети между АОС и СУБД? Какая задержка? Точно ли это один физический свич или нормально настроен виртуальный свич в системе виртуализации?

СУБД случайно не на виртуальном сервере?
__________________
Ivanhoe as is..
Старый 12.09.2018, 12:02   #9  
Masel is offline
Masel
Участник
 
39 / 527 (18) +++++++
Регистрация: 19.09.2007
БД модели обслуживается, дефрагментации почти нет, т.к. каждый понедельник после релиза все индексы в ней ребилдятся. Статистика собирается по ней фулсканом, т.к. база небольшая.

С производительностью аосов все в порядке, по крайней мере ресурсы показывают низкую загрузку (процессоры, память и т.д.)
Между аосом и субд 10 гигабит, они вообще в одной виртуальной среде, там нормально настроен свитч в виртуальной среде. Пинги <1, перекачка файла показывает 90+ мегабайт в секунду.

Субд на виртуальном, как и аосы и терминалы. Но судя по queryvalue тормозит именно аос, а не БД (хотя нельзя исключать каких-то фоновых вызовов к метаданным модели). Кроме queryValue заметил еще аномалии в работе табличного кэша - чтение и запись. И еще показывает тормоза после метода super() в inventTrans.insert, inventTrans.update.

Все это проявляется не постоянно, а время от времени, обычно под нагрузкой. Пока поиски причины продолжаются.
Старый 12.09.2018, 12:27   #10  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2155 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Попробовать перейти на железный скуль не реально?
Поищу какая была скорость сети на виртуале и что получилось на физике. Судя по симптомам проблема именно в виртуализации. Кстати она какая?
__________________
Ivanhoe as is..
Старый 12.09.2018, 13:30   #11  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,865 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от Masel Посмотреть сообщение
С производительностью аосов все в порядке, по крайней мере ресурсы показывают низкую загрузку (процессоры, память и т.д.)
Низкая загрузка проца еще ни о чем не говорит. Возможно в диск упирается. Проверяйте дисковые очереди.
За это сообщение автора поблагодарили: vmoskalenko (2).
Старый 12.09.2018, 13:55   #12  
Masel is offline
Masel
Участник
 
39 / 527 (18) +++++++
Регистрация: 19.09.2007
Цитата:
Сообщение от Logger Посмотреть сообщение
Низкая загрузка проца еще ни о чем не говорит. Возможно в диск упирается. Проверяйте дисковые очереди.
Очереди к дискам низкие. Если речь про аос, то там вообще минимальный обмен с диском, измеряется килобайтами в секунду.
Старый 12.09.2018, 13:57   #13  
Masel is offline
Masel
Участник
 
39 / 527 (18) +++++++
Регистрация: 19.09.2007
Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
Попробовать перейти на железный скуль не реально?
Поищу какая была скорость сети на виртуале и что получилось на физике. Судя по симптомам проблема именно в виртуализации. Кстати она какая?
Перейти можно. Но пока не вижу проблемы именно в СУБД, чтобы переходить, но вообще этот вопрос обсуждается. Виртуализация VMWare.
Старый 12.09.2018, 15:55   #14  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2155 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Статистика по внедрениям ax 2012, о которых я знаю, говорит, что переход на физический скуль всегда даёт большой прирост общей производительности. Даже когда формально виртуальные сервера отдыхают по счётчикам.
Уже сколько то лет мы пишем обязательность физического сервера бд в спецификациях заказчикам.
__________________
Ivanhoe as is..

Последний раз редактировалось Ivanhoe; 12.09.2018 в 15:57.
За это сообщение автора поблагодарили: Logger (3).
Старый 12.09.2018, 16:24   #15  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,865 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от Masel Посмотреть сообщение
Очереди к дискам низкие. Если речь про аос, то там вообще минимальный обмен с диском, измеряется килобайтами в секунду.
А вы их внутри виртуалки смотрели ?
Или еще на железяке под которой она крутится?
Старый 14.09.2018, 14:02   #16  
БАХ43 is offline
БАХ43
Участник
 
92 / 54 (2) ++++
Регистрация: 15.02.2013
Адрес: г.Москва, г. Зеленоград
Цитата:
Сообщение от Masel Посмотреть сообщение
И еще показывает тормоза после метода super() в inventTrans.insert, inventTrans.update.
Тоже было при завершении транспортировок. Ковырялся долго, нашел такой баг: В классе InventUpd_Financial, в методе updateFinancialIssue есть вызов this.updateInventOnhandFinancialCache(inventTrans);
А в методе updateFinancialReceipt этот вызов проходит с условием if (movement.inventModelType().stdCostBased())
Поставил такое же условие в updateFinancialIssue. Помогло. Но у нас Аксапта заточена только физические проводки, финансовых нет. Поэтому точно не могу сказать - а не поломается ли что-то из-за этого условия.
Ой может не в тему. У нас 2009.
__________________
Я прибыл к вам из Кантемировской дивизии. А там, как известно, дураков не держат!

Последний раз редактировалось БАХ43; 14.09.2018 в 14:05.
Старый 09.02.2022, 20:42   #17  
SRF is offline
SRF
Участник
MCBMSS
Axapta Retail User
 
362 / 542 (19) +++++++
Регистрация: 08.08.2007
Записей в блоге: 1
На одном клиенте были подобные симптомы, периодически падала производительность одной пакетной многопоточной операции (обработка входящих документов - создание и разноска заказов на продажу, обработка накладных, обработка перехода права собственности (ппс) и т.д. в многопоточном режиме), при этом на БД - ок, а АОС работает как черепашка.

Удалось обнаружить вот такую зависимость :

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

Снимали трассировку и там примерно такие же проблемы - queryValue, табличный кеш, с парсингом xml какие-то затыки возникали(был еще запрос в коробке, который тоже на длительных операциях проявляется, но он легко оптимизируется).

При этом я смотрел потребление памяти службой АОСа - после запуска потребление памяти резко росло (в течении пары минут съедалось несколько гигабайт), но даже если ПО работала существенно дольше, например, 12 часов то как правило объем памяти не превышал 18-20 ГБ (точных цифр не вспомню, но мне кажется больше 20ки я не видел).

В целом есть ли связь именно с объемом потребляемой памяти - типа условно, после XXX гб АОС начинает тупить, не знаю, не уверен, у меня скорее гипотеза в том, что когда порог неутилизированной памяти(т.е. та, которую можно было бы уже освободить) превышает определенный порог, то у АОСа начинаются проблемы.

Пока пытался разобраться натыкался где-то на рекомендацию, на каждый ресурсоемкий поток выделять отдельное ядро, ну такое, не знаю, у нас уже ломалось на 24 потоках хотя на аосе 32 ядра.

В целом вот еще интересная статья по теме памяти (думаю видели, но на всякий случай оставлю ссылку тут) - https://cloudblogs.microsoft.com/dyn...in-xppil-code/

Хоть к теме и не относится, я вот пока ни на одном проекте еще не видел, чтобы где в то кастомизациях query\queryrun finalize вызывался.

На клиенте пока ничего не стали делать - при необходимости, просто в ребут ПО отправляют ) Правда, думаю это временно, когда будет достигнут предел пропускной способности придется таки заняться оптимизацией потребляемой памяти, хотя может быть и не в ближайшем будущем.
__________________
Sergey Nefedov
За это сообщение автора поблагодарили: Vadik (1), Logger (5), Masel (8).
Старый 09.02.2022, 22:05   #18  
Masel is offline
Masel
Участник
 
39 / 527 (18) +++++++
Регистрация: 19.09.2007
Я эту проблему решил потом. Нужно отключить серверную сборку мусора. Тормозить она насколько я помню начинает, когда включается сборка при большом потреблении памяти. С клиентской сборкой она включается на малых величинах и проблемы не возникает.
За это сообщение автора поблагодарили: fed (3), Vadik (1), Logger (1), SRF (5).
Старый 10.02.2022, 08:07   #19  
SRF is offline
SRF
Участник
MCBMSS
Axapta Retail User
 
362 / 542 (19) +++++++
Регистрация: 08.08.2007
Записей в блоге: 1
Да, отключение серверной сборки мусора рассматривается как один из возможных вариантов, удобно не надо в коде ничего менять, я даже немного поигрался с ним в прод окружении.

Первоначально проверял на железном АОСе, там была забавная ситуация, перекинули туда только эту ПО, поставили 64 потока, ну думаем сейчас будет космос, но не тут то было - в режиме сервера он за считанные минуты съел +30ГБ и стал работать очень медленно, как результат скорость обработки документов была ниже в 2-3 раза, чем на виртуальном

Переключил в режим клиента, объем памяти не поднимался выше 10 ГБ, даже при работе несколько часов и скорость обработки стала в 2-3 раза быстрее, чем на виртуальном, при этом глюков с тормозами в queryValue и т.д. не наблюдалось.

Включили на виртуальном, и обнаружился интересный артефакт - ПО, которые работали не под админом стали работать существенно медленнее (у клиента почти все ПО работают под админом, но есть парочка, которые работают под выделенными учетками), появились постоянные запросы к метаданным и правам (обычно такую картинку наблюдаешь при изменении прав, которая в некоторых случаях приводит к фризу АОСа, но там по крайней мере понятно, что является источником, типа права поменяли, кеш обновляется, можно через axutil обновить кеш и т.д.), здесь возможно как то кеш начал регулярно обновляться, возможно просто что-то другое совпало, но предметно уже не анализировали.
__________________
Sergey Nefedov
Старый 10.02.2022, 11:05   #20  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,865 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от Masel Посмотреть сообщение
Я эту проблему решил потом. Нужно отключить серверную сборку мусора. Тормозить она насколько я помню начинает, когда включается сборка при большом потреблении памяти. С клиентской сборкой она включается на малых величинах и проблемы не возникает.
А где отключали?
На аосе?
На клиенте?
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
emeadaxsupport: Documentation collection: Inplace upgrade MS Dynamcis AX 2012 RTM --> AX 2012 R2 CU7 Blog bot DAX Blogs 0 22.06.2014 01:19
axsa: MDM Adapter - Extending Dynamics AX 2012 R3 Master Data Management Blog bot DAX Blogs 0 22.05.2014 03:28
DAX: Official Dynamics AX 2012 R2 Content (update) - Where is it, and how can you find out about updates? Blog bot DAX Blogs 0 03.12.2012 11:11
Dynamics AX Sustained Engineering: Servicing of Dynamics AX 2012 and Dynamics AX 2012 Feature Pack Blog bot DAX Blogs 0 08.05.2012 23:12
dynamics-ax: Interview with Microsoft's Lachlan Cash on his new role, AX 2012 and more Blog bot DAX Blogs 6 22.04.2011 14:55
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 08:10.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.