А построение перекрестных ссылок опять сожрет всю память и завесит систему нафих

[Alex_K]

Mazzy: Выделено отсюда: Microsoft Dynamics AX 4.0: Результаты тестирования производительности

Угу... А построение перекрестных ссылок опять сожрет всю память и завесит систему нафих

[mazzy]

Цитата:

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

Угу... А построение перекрестных ссылок опять сожрет всю память и завесит систему нафих

Перекрестные ссылки в 4ой международной Аксапте весят 2.5 гига.
Построенные перекрестные ссылки не мешают работе.

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

[Alex_K]

Цитата:

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

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

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

[Андре]

Цитата:

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

Построение перекрестных ссылок дучше делать частями, а не всем скопом сразу. Например, сначала классы, потом таблицы, потом формы и т.д. В этом случае, меньше вероятность, что системе не хватит оперативной памяти и начнется работа со свопом.

[mazzy]

Цитата:

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

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

Странно. У меня построил сравнительно быстро.

Скорее всего, у вас SQL2005 и скорее всего настроено автоувеличение базы (autogrowth) на 1Мб (это параметры по умолчанию).
Если так, то извините... Думать же надо.
Еще раз: размер перекрестных ссылок - около 2.5 Гб.
До построения перекрестных ссылок задайте соответствующий размер базы, или переключите autogrowth хотя бы на 10%.

[mazzy]

Цитата:

Сообщение от Андре

Построение перекрестных ссылок дучше делать частями, а не всем скопом сразу. Например, сначала классы, потом таблицы, потом формы и т.д. В этом случае, меньше вероятность, что системе не хватит оперативной памяти и начнется работа со свопом.

На самом деле, пользоваться этим советом стоит с осторожностью.
Особенно новичкам.

Утечку памяти, похоже, победили. Тьфу-тьфу-тьфу.
Посмотрим, что будет в 4.0.1, на которой будет основана русская версия.

[Alex_K]

Да, параметры SQL-сервера я действительно не менял, впредь буду думать
Но процесс встрял именно из-за того, что съел всю виртуальную память.
Кстати, это и была Preview русской версии...

[mazzy]

Цитата:

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

Кстати, это и была Preview русской версии...

Спасибо.
А билд ядра какой?

[Alex_K]

2103.
Российская функциональность пока накатывается ручным копированием слоёв gls и los.

[mazzy]

Цитата:

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

2103.

Спасибо.
Если у вас есть возможность и желание, то попробуйте выпросить более старший билд.
Решилась ли проблема в новом билде?
У не ставил себе этот. В старых и в более новых Аксапта виртуальную память не жрала, насколько я помню...

И еще. У вас установки своп-файла какие?
Я всегда устанавливаю фиксированный размер, равный оперативной памяти.
А у вас как?

[glibs]

Цитата:

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

...
Перекрестные ссылки в 4ой международной Аксапте весят 2.5 гига.
...

Правда, чтоли?

В русской 4.0 сп1 у меня примерно так
name.........................rows............reserved....data..........index_size...unused
XREFREFERENCES...4 381 547....913 320.....365 136....547 920.......264
XREFPATHS...............580 314......272 848.....157 600....115 112.......136
XREFNAMES..............361 057......83 800.......42 784......40 840.........176

Т.е. примерно 1.25 Гб.

А то я уже было испугался.

Их что, стало меньше?

А насчет ступора... у меня клиент выжрал 1.5 Гб виртуальной памяти примерно. Но не сдох. По его словам процесс обновления занял 3:45. Потом по моей команде он закрывался. Долго и мучительно :-)

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

А вообще на трешке перекрестные ссылки хоть и весили поменьше, но строились существенно быстрее. Будем надеяться, что функционал стал работать быстрее, как пишут некоторые :-)

[alex55]

Цитата:

Сообщение от Андре

Построение перекрестных ссылок дучше делать частями, а не всем скопом сразу. Например, сначала классы, потом таблицы, потом формы и т.д. В этом случае, меньше вероятность, что системе не хватит оперативной памяти и начнется работа со свопом.

Дополню, что также можно обновлять только ссылки определенного слоя, отфильтровав по utilLevel и поставив флажок "Выбрано" перед запуском - может быть полезно для получения актуального состояния для текущих разработок на верхнем слое, например usr. Соответственно время обновления и требования к памяти гораздо меньше, в соответствии с размером выбранного слоя/слоев.

[sukhanchik]

Цитата:

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

Дополню, что также можно обновлять только ссылки определенного слоя, отфильтровав по utilLevel и поставив флажок "Выбрано" перед запуском - может быть полезно для получения актуального состояния для текущих разработок на верхнем слое, например usr. Соответственно время обновления и требования к памяти гораздо меньше, в соответствии с размером выбранного слоя/слоев.

Хе... А Вы так пробовали делать?
Вариант 1. Первый раз строим все ссылки, затем обновляем только по слою.
Эффект 1. Если мне не изменяет память (т.к. быстро отказался от этого варианта) - то не обновляются ссылки на использование объектов с других слоев. Т.е. если мы, к примеру в коде на usr-слое использовали InventTable, то перекрестные ссылки по InventTable об этом ничего не скажут.
Эффект 2. Будет задвоение (неоднократно видел собственными глазами). Т.е. в форме "Чем используется" каждая запись будет задвоена, затроена и т.д. для каждого построения ссылок.

Вариант 2. Ставим галочку "Удалить все". Но это удаляет ВСЕ записи - т.о. мы имеем ссылки только по usr-слою без sys и прочих слоев. Но в этом случае нет задвоения. Наблюдается ли эффект 1 - точно не помню - уж больно проверить все это временнозатратно.

На ноуте надо ограничивать память для SQL Server либо строить ссылки не на ноуте, а затем переливать таблички Xref*. Самый удобный на мой взгляд вариант - регулярный запуск на сервере построения ссылок ночью (ярлычок с axc-шником с параметром автозапуска compileAll_+). При этом еще для ускорения можно выполнить truncate для xRef*-таблиц до построения ссылок.
Плюс - уровень компилятора д.б. не больше 3 (а то и 2) - иначе может не хватить памяти для формирования лога

[alex55]

Цитата:

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

Хе... А Вы так пробовали делать?
Вариант 1. Первый раз строим все ссылки, затем обновляем только по слою.
Эффект 1. Если мне не изменяет память (т.к. быстро отказался от этого варианта) - то не обновляются ссылки на использование объектов с других слоев. Т.е. если мы, к примеру в коде на usr-слое использовали InventTable, то перекрестные ссылки по InventTable об этом ничего не скажут.
Эффект 2. Будет задвоение (неоднократно видел собственными глазами). Т.е. в форме "Чем используется" каждая запись будет задвоена, затроена и т.д. для каждого построения ссылок.

Вариант 2. Ставим галочку "Удалить все". Но это удаляет ВСЕ записи - т.о. мы имеем ссылки только по usr-слою без sys и прочих слоев. Но в этом случае нет задвоения. Наблюдается ли эффект 1 - точно не помню - уж больно проверить все это временнозатратно.
...
Плюс - уровень компилятора д.б. не больше 3 (а то и 2) - иначе может не хватить памяти для формирования лога

Пробовал, но пока еще изучаю на предмет подводных камней.

Проверил описанные эффекты на DAX 4.0 SP2:
Вариант 1.
Эффект 1: Не проявился. После обновления ссылка на InventTable появилась. Если я правильно понимаю, то при обновлении ссылок для объекта, мы получаем записи по всем объектам на которые он ссылается. Соответственно обновлять ссылки на объекты с нижележащих слоев, чтобы узнать какие объекты на них ссылаются, не нужно.

Эффект 2. Задвоения пока не обнаружил, хотя поведение системы мне не очень понятно. На скриншоте показано изменение кол-ва записей в таблицах при последовательном обновлении ссылок на usr без изменения объектов. То есть после 7-ой итерации кол-во записей не меняется, а на промежуточных итерациях меняется по странному алгоритму.

Кстати, а что за лог, связанный с уровнем диагностики компилятора? Мне казалось что при обновлении ПС вывод диагностики не производится..

[sukhanchik]

При запуске из командной строки с параметром compileAll_+ производится построение ссылок вместе с перекомпиляцией, и соотв выводится лог ошибок компиляции. Просто в зависимости от уровня компилятора туда могут попасть ошибки, предупреждения, TODO-шки, информация о Best Practice. Лог сохраняется в папке LogDir (см конфиг файл). Чем больше туда попадает информации - тем больше кушается оперативная память.

По поводу Эффекта 1 - я этого тоже вроде не наблюдал - но мне как-то сказали "авторитетные" люди - а я не проверял. Возможно это и не наблюдается - просто уже не помню.
По поводу Эффекта 2 - скажу лишь - что все это я наблюдал на 3.0 SP2 и SP3 CU1 + ядрах от KR1 до KR3. На 4.0 SP2 мы как-то сразу решили запускать построение ссылок каждую ночь, после чего проблем не наблюдали, но иногда (не всегда) - замечали, что ссылки на некоторые объекты не были обновлены (это тоже не сразу замечаешь). Truncate Table Xref* (т.е. очистка таблиц) перед построением ссылок решило эту проблему и ссылки стали строиться гарантированно полно.

[DSPIC]

Задвоение перекрёстных ссылок