AX 2012 - глюки ядра

[Masel]

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

Конкретно этот пример AX 2012 R2, ядро 6.2.3000.5063. Код в CIL в пакете. В тот же момент проходил пересчет склада в 32 потока. Различные артефакты подобного рода наблюдаю и в других ситуациях, CIL, не CIL, иногда бывают тормоза на методах, которые вызывают strfmt() и больше вообще ничего. Перезагрузка аоса обычно лечит все такие ситуации, в CIL иногда становится лучше и без перезагрузки.

[Logger]

Исчерпывающего ответа у меня нет, но есть наводящие мысли.

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

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

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

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

У вас как раз идет работа со строкой.

[Logger]

В вашем случае вместо QueryValue(parameter) для енума можно попробовать написать просто int2str(parameter)
Результат по идее будет тот же, но надеюсь, что побыстрее сработает.

[Masel]

Цитата:

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

В вашем случае вместо QueryValue(parameter) для енума можно попробовать написать просто int2str(parameter)
Результат по идее будет тот же, но надеюсь, что побыстрее сработает.

Написать можно конечно, даже может быть оно поможет конкретно в этом месте. Но таких мест огромное количество, в данном случае это стандартный функционал - резервирование InventSum::newQueryReservation. В общем печаль. О том, что трейспарсер показывает что-то не то, я тоже думал, но функционал реально тормозит и везде при различных сценариях вызова тормозит queryvalue в данной трассировке. Думаю если бы дело было только в трейспарсере то в зависимости от стека вызова, соседних вызовов и т.д. время раскидывалось на разные методы.
Такого рода глюки кстати наблюдал и ранее и не только на этом приложении, не только в этой компании.

[Logger]

Получается что тормозит enum2value()
но метод состоит из нескольких вызов функций ядра.
может посмотреть какая из них тупит ?

Возможно аналогичный вызов и в других местах дает тормоза.

[DSPIC]

какая-то кустарщина в enum2value написана, никогда туда не заглядывал. Вдобавок, медленный reflection. Я бы подкэшировал (globalCache) и отпустил с миром.

[DSPIC]

ещё одна мысль: strfmt('%1', E) очевидно обращается к Labels, которые можно попробовать переиндексировать (снести *.ali, *.alc).

[Ivanhoe]

Наблюдал такое на нескольких инсталляциях.
Основные два вопроса: обслуживаете ли вы БД модели и что у вас в целом с производительностью АОС серверов.

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

СУБД случайно не на виртуальном сервере?

[Masel]

БД модели обслуживается, дефрагментации почти нет, т.к. каждый понедельник после релиза все индексы в ней ребилдятся. Статистика собирается по ней фулсканом, т.к. база небольшая.

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

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

Все это проявляется не постоянно, а время от времени, обычно под нагрузкой. Пока поиски причины продолжаются.

[Ivanhoe]

Попробовать перейти на железный скуль не реально?
Поищу какая была скорость сети на виртуале и что получилось на физике. Судя по симптомам проблема именно в виртуализации. Кстати она какая?

[Logger]

Цитата:

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

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

Низкая загрузка проца еще ни о чем не говорит. Возможно в диск упирается. Проверяйте дисковые очереди.

[Masel]

Цитата:

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

Низкая загрузка проца еще ни о чем не говорит. Возможно в диск упирается. Проверяйте дисковые очереди.

Очереди к дискам низкие. Если речь про аос, то там вообще минимальный обмен с диском, измеряется килобайтами в секунду.

[Masel]

Цитата:

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

Попробовать перейти на железный скуль не реально?
Поищу какая была скорость сети на виртуале и что получилось на физике. Судя по симптомам проблема именно в виртуализации. Кстати она какая?

Перейти можно. Но пока не вижу проблемы именно в СУБД, чтобы переходить, но вообще этот вопрос обсуждается. Виртуализация VMWare.

[Ivanhoe]

Статистика по внедрениям ax 2012, о которых я знаю, говорит, что переход на физический скуль всегда даёт большой прирост общей производительности. Даже когда формально виртуальные сервера отдыхают по счётчикам.
Уже сколько то лет мы пишем обязательность физического сервера бд в спецификациях заказчикам.

[Logger]

Цитата:

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

Очереди к дискам низкие. Если речь про аос, то там вообще минимальный обмен с диском, измеряется килобайтами в секунду.

А вы их внутри виртуалки смотрели ?
Или еще на железяке под которой она крутится?

[БАХ43]

Цитата:

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

И еще показывает тормоза после метода super() в inventTrans.insert, inventTrans.update.

Тоже было при завершении транспортировок. Ковырялся долго, нашел такой баг: В классе InventUpd_Financial, в методе updateFinancialIssue есть вызов this.updateInventOnhandFinancialCache(inventTrans);
А в методе updateFinancialReceipt этот вызов проходит с условием if (movement.inventModelType().stdCostBased())
Поставил такое же условие в updateFinancialIssue. Помогло. Но у нас Аксапта заточена только физические проводки, финансовых нет. Поэтому точно не могу сказать - а не поломается ли что-то из-за этого условия.
Ой может не в тему. У нас 2009.

[SRF]

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

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

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

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

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

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

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

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

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

На клиенте пока ничего не стали делать - при необходимости, просто в ребут ПО отправляют ) Правда, думаю это временно, когда будет достигнут предел пропускной способности придется таки заняться оптимизацией потребляемой памяти, хотя может быть и не в ближайшем будущем.

[Masel]

Я эту проблему решил потом. Нужно отключить серверную сборку мусора. Тормозить она насколько я помню начинает, когда включается сборка при большом потреблении памяти. С клиентской сборкой она включается на малых величинах и проблемы не возникает.

[SRF]

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

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

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

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

[Logger]

Цитата:

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

Я эту проблему решил потом. Нужно отключить серверную сборку мусора. Тормозить она насколько я помню начинает, когда включается сборка при большом потреблении памяти. С клиентской сборкой она включается на малых величинах и проблемы не возникает.

А где отключали?
На аосе?
На клиенте?