Перекрестные ссылки в AX2009 долго обновляются

[Kostiki]

Подскажите пожалуйста, запустил обновление перекрестных ссылок. Стояли все галочки. Запустил на тестовом AOS, которым никто не пользуется. Запустил 23 августа. Больше двух недель, полет нормальный. Ссылки перестраиваются до сих пор. Что может быть? Такое чувство, что где то обновление зациклилось.

[gl00mie]

При обновлении перекрестных ссылок код приложения обходит AOT и дергает ядро, чтобы оно сгенерировало ссылки для соотв. узла. Затем код сбрасывает полученные результаты в таблицы перекрестных ссылок. "Зациклиться" оно по идее не должно, скорее всего, дело в том, что сброс результатов в таблицы (а он включает в себя и поиск в уже сгенерированных данных, см., скажем, \Data Dictionary\Tables\xRefNames\Methods\findOrInsert) идет слишком медленно. А еще при обновлении перекрестных ссылок AOS очень агрессивно кэширует объекты приложения в памяти и отъедает этой памяти до нескольких гигов. Так что, возможно, на хосте тестового AOS'а мало памяти, или база крутится на медленных винтах, или СУБД настроена неоптимально, или для СУБД мало памяти, или всё перечисленное в каких-то комбинациях. Помониторьте в СУБД обращения к xRef*-таблицам, а также использование памяти на хосте тестового AOS'а, посмотрите задержки, очереди ввода-вывода...
В нормальных условиях при достаточном количестве ресурсов и не очень сильно кастомизированном приложении перекрестные ссылки в AX 2009 успевают собраться за ночь, см. также опрос Сколько времени у вас занимает сбор перекрестных ссылок по вашему приложению AX 4.0/2009?

[sukhanchik]

Цитата:

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

Подскажите пожалуйста, запустил обновление перекрестных ссылок. Стояли все галочки. Запустил на тестовом AOS, которым никто не пользуется. Запустил 23 августа. Больше двух недель, полет нормальный. Ссылки перестраиваются до сих пор. Что может быть? Такое чувство, что где то обновление зациклилось.

А почему Вы решили, что ссылки до сих пор перестраиваются? Потому что клиент висит? Если да, то это не показатель. Посмотрите через SQL Management Studio - добавляются ли записи в таблички xRef* (можно задать запросы на подсчет количества записей и выполнять эти запросы в течении некоторого промежутка времени, чтобы посмотреть - меняется ли количество записей).
Также можно посмотреть в табличке xRefPaths дату и время создания и изменения записи и, соответственно, выбрать самую свежую, чтобы понять, когда последний раз сюда "лазили".

Ну и конечно - сам процесс будет действительно отрабатывать существенно медленнее, если:
- сервер недостаточной мощности (память, процессоры, скорость жестких дисков)
- приложение до этого не компилировалось (особенно, если это инсталляция "с нуля")
- процесс запущен не на том сервере, где физически лежит папка с приложением (верно для АХ2009 и более старых версий)

[Logger]

Кстати да.
Встречался именно с таким поведением. Сбор перекрестных ссылок завершался успешно, но клиент почему-то висел, не завершая своей работы. (У меня стоит запись в табличный лог в процессе сбора ссылок, судя по логу, класс их сбор отрабатывал полностью, а клиент ax32 все равно работал.)
Как правило такое было при уходе в своп.

[Kostiki]

Обновление запустил на сервере с AOS. Сам сервер AOS и клиент откушали по полтора гига памяти. На сервере еще 8 гигов свободно. Загрузка проца 5%. 8 логических процессоров. Сервер SQL имеет на борту 24 гига памяти, из них 16,5 слопал сам SQL сервер. Загрузка проца 5%. 8 логических процессоров. Тест лисковой подсистемы показывает 1500 IOPS, вроде бы как выше крыши должно хватать на обновление перекрестных ссылок.
Приложение немного кастомизированное. Перекрестные ссылки в базе занимают в районе 4 гигабайт.

Почему решил что обновление до сих пор идет? Потому что на клиенте периодически меняется названием объекта, по которому идет обновление ссылок.

Теперь немного странности. Посмотрел на созданные записи в XREFREFERENCES. И был немного удивлен. Очень много записей за 23 августа. , несколько записей за 24 августа. И после этого пять записей за 27, 28, 31 августа и 3 сентября. Он что, тратит по нескольку дней на обновление одной ссылки?

[Logger]

Не должен он столько тратить. Часов за 6-12 всегда собирались.

Поставьте логирование его действий в текстовый файл (сами ручками пропишите в классе сбора ссылок).
Это сильно производительность не просадит, зато поймете где тупит.

[mazzy]

Цитата:

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

Посмотрел на созданные записи в XREFREFERENCES. И был немного удивлен. Очень много записей за 23 августа. , несколько записей за 24 августа. И после этого пять записей за 27, 28, 31 августа и 3 сентября. Он что, тратит по нескольку дней на обновление одной ссылки?

он не тратит.

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

на перекрестные ссылки в последних версиях нужно 2-3Гб.

скорее всего, у вас все это время SQL занимается увеличением файла с базой на диске. Измените параметры на SQL.
Во-первых, сразу установите размер базы таким, чтобы было свободным 5-6Гб
Во-вторых, уберите автошринк
В-третьих, установите прирост базы в 100-200 Мб

[Kostiki]

Цитата:

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

он не тратит.

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

на перекрестные ссылки в последних версиях нужно 2-3Гб.

скорее всего, у вас все это время SQL занимается увеличением файла с базой на диске. Измените параметры на SQL.
Во-первых, сразу установите размер базы таким, чтобы было свободным 5-6Гб
Во-вторых, уберите автошринк
В-третьих, установите прирост базы в 100-200 Мб

Стоит прирост 500Мб. Текущий размер базы 50 Гб. Таблицы xRef, которые обновлялись последний раз пару лет назад суммарно занимают в базе 4 Гб. Автошринка нет.

[Damn]

Какая версия у ядра АОСа, приложения и клиента ? Совпадает у всех трёх ?
В таблицах и классах xRef ничего кроме слоя sys нет ?