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

[Masel]

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

[SRF]

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

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

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

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

[Logger]

Цитата:

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

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

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

[Masel]

Цитата:

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

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

Отключал на аосе. В bin папке аоса в конф. файле меняется <gcServer enabled="false" />.
На клиенте я даже не знаю, есть ли такая настройка, ни разу не проверял. Но с клиентом проще. Там обычно все в один поток и пользователь может переоткрыть клиент, пока жалоб на клиент не поступало. Все тяжелые операции обычно на сервере.
Эта настройка уже несколько лет работает в продуктиве на всех аосах, и клиентских и пакетниках. Я за это время особо негативных побочных эффектов не увидел, хотя лучше наверное включать только если реально диагностируется проблема.

Я когда когда эту проблему исследовал, то наиграл воспроизводимый пример. В этом примере в таблицу InventParameters было добавлено несколько тяжелых полей и были частые обращения InventParameters::find() в джобе. Есть определенная граница в размере таблицы, после которой все начинает жутко тупить. Я предположил, что как то плохо собирается мусор от больших курсоров. Но возможно это не единственный триггер, и четких критериев нет.

Уже после того как я этот параметр нашел мне удалось этот пример отправить в майкрософт и мне в итоге прислали рекомендацию как раз этот параметр и использовать.

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

[Logger]

Цитата:

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

На клиенте я даже не знаю, есть ли такая настройка, ни разу не проверял.

Есть (Потому я и спросил. Из описания не понял, ваши проблемы только в пакетах наблюдались или и в клиентском коде тоже. Ну теперь разъяснили)

см.
Ax32.exe.config

Но там параметр не выставлен. Т.е. используется по умолчанию.

[vmoskalenko]

Цитата:

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

Я когда когда эту проблему исследовал, то наиграл воспроизводимый пример. В этом примере в таблицу InventParameters было добавлено несколько тяжелых полей и были частые обращения InventParameters::find() в джобе. Есть определенная граница в размере таблицы, после которой все начинает жутко тупить. Я предположил, что как то плохо собирается мусор от больших курсоров. Но возможно это не единственный триггер, и четких критериев нет.

Проверьте какой уровень кеширования выставлен в таблице InventParameters

Если установлено Entire Table то вся таблица всасывается в локальную память. Проблема в том что той памяти выделяется аж 128Кбайт (если память не изменяет).
В Dynamics Perf есть отдельный query на эту тему.

[Masel]

Цитата:

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

Проверьте какой уровень кеширования выставлен в таблице InventParameters

Если установлено Entire Table то вся таблица всасывается в локальную память. Проблема в том что той памяти выделяется аж 128Кбайт (если память не изменяет).
В Dynamics Perf есть отдельный query на эту тему.

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