RecRef'ы и утечка памяти - NAV: Программирование

Romul · 24.07.2012, 19:46

Всем привет.

Гигантская проблема возникает при работе с рекрефами: утечка памяти...
Согласно мибусо и другим умным источникам - необходим перенос рекрефов и филдрефов в локальные переменные функции/процедуры. Якобы поможет.
Сделал, протестировал - не помогло. Закрываю все рекрефы вовремя - не помогает.
Билд 5.0.26084.0

Если кто сталкивался/решал проблему - прошу помочь советом.

**Sancho** · 24.07.2012, 23:59

подписываюсь на тему, ибо часто работаю с рефами, просто интересно.
сам проблемы такой не встречал.

artkashin · 25.07.2012, 11:02

Цитата:

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

Всем привет.

Гигантская проблема возникает при работе с рекрефами: утечка памяти...
Согласно мибусо и другим умным источникам - необходим перенос рекрефов и филдрефов в локальные переменные функции/процедуры. Якобы поможет.
Сделал, протестировал - не помогло. Закрываю все рекрефы вовремя - не помогает.
Билд 5.0.26084.0

Если кто сталкивался/решал проблему - прошу помочь советом.

Рома, а логгирование изменений, что в народе Change Log management, в включенном состоянии тоже приводит к подобным утечкам? Пробовал на более старых билдах?

Romul · 25.07.2012, 18:15

Цитата:

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

Цитата:

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

Всем привет.

Гигантская проблема возникает при работе с рекрефами: утечка памяти...
Согласно мибусо и другим умным источникам - необходим перенос рекрефов и филдрефов в локальные переменные функции/процедуры. Якобы поможет.
Сделал, протестировал - не помогло. Закрываю все рекрефы вовремя - не помогает.
Билд 5.0.26084.0

Если кто сталкивался/решал проблему - прошу помочь советом.

Рома, а логгирование изменений, что в народе Change Log management, в включенном состоянии тоже приводит к подобным утечкам? Пробовал на более старых билдах?

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

Romul · 25.07.2012, 20:00

В общем, в DUPLICATE причина... Полено и есть... Зато "Dynamics NAV" и блатной ребрендинг.

Бегаю в цикле по 17-й с парой миллионов записей, первым рекрефом. Когда в этом цикле делаю дупликейт на вторым рекрефом на первый - начинается проблема с памятью. Даже когда тут же закрываю второй рекреф.
Но когда в этом цикле делаю вторым рекрефом открытие 17-й и наложение тех же самых фильтров (точная копия первого рекрефа, но без дупликейта) - все работает нормально.
Может кто попробует на своих рабочих базах просто в цикле по паре миллионов операций пробежаться и для каждой из них делать дупликейт?

ЗЫ: похоже, у чела была аналогичная проблема...
http://forum.mazzy.ru/index.php?show...ndpost&p=16125

Romul · 25.07.2012, 20:41

В общем, я не знаю как это комментировать...
Есть, скажем, процедура у меня. Называется она, допустим, Proc1. И есть в этой процедуре следующий кусок кода (переменные RecRef и RecRef2 - локальные). Бегаю я только по 17-й таблице с парой миллионов записей, предварительно натравив рекрефу на 17-ю, разумеется:

Proc1()
IF RecRef.FIND('-') THEN BEGIN
REPEAT
RecRef2 := RecRef.DUPLICATE;
RecRef2.CLOSE;
UNTIL RecRef.NEXT = 0;

Система в этом случае валится через непродолжительное время.

Делаю следующее изменение...

Proc1()
IF RecRef.FIND('-') THEN BEGIN
REPEAT
Proc2(RecRef,RecRef2);
RecRef2.CLOSE;
UNTIL RecRef.NEXT = 0;

Proc2(VAR RecRefFrom,VAR RecRefTo)
RecRefTo := RecRefFrom.DUPLICATE;

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

Серж, Артем, спасибо за дискуссию. Хренову тучу времени убил на этот ад. Может кому эта фигня тоже полезной окажется...

ЗЫ: коллеги, попробуйте на своих больших базах подобное. Возможно, конфа сервера влияет...

**Sancho** · 26.07.2012, 00:55

тебе спасибо!
+1

rmv · 26.07.2012, 17:24

Забавный глюк. Похоже чистка мусора запускается после выхода процедуры или функции.

Romul · 26.07.2012, 23:56

Цитата:

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

Забавный глюк. Похоже чистка мусора запускается после выхода процедуры или функции.

Да, возможно.
На кривую конфу сервера тоже не похоже. Ибо на моей локальной 32-битной машине то же самое. Причем я был неправ насчет отсутствия проблемы в 2009. И там косяк...

alexb_imported · 27.07.2012, 00:18

Цитата:

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

IF RecRef.FIND('-') THEN BEGIN
REPEAT
RecRef2 := RecRef.DUPLICATE;
RecRef2.CLOSE;
UNTIL RecRef.NEXT = 0;

Система в этом случае валится через непродолжительное время.

Запустил этот код у себя на 5-ке (Build 25560, 26084 как у вас, под рукой не окзался) для 2 млн. записей: всё ОК, система не валится, так же ОК если не делать RecRef2.CLOSE (зачем вообще делать CLOSE если вы не делаете до этого OPEN?).
Что вы вообще потом делаете с RecRef2 после duplicate? Если хотите в цикле после каждого duplicate 100% очистить RecRef2, то сделайте просто CLEAR(RecRef2), и правильнее будет даже CLEAR сделать до duplicate.
Может у вас всё же в коде программа впадает в бесконечный цикл из за неложенных фильтров?
По поводу производительности: по-видимому в recref та же технология как и в темповых rec-переменных, у этих тоже с определённого числа записей производительность падает, т.к. темповые таблицы грузятся в память клиента.

Romul · 27.07.2012, 01:16

Цитата:

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

Цитата:

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

IF RecRef.FIND('-') THEN BEGIN
REPEAT
RecRef2 := RecRef.DUPLICATE;
RecRef2.CLOSE;
UNTIL RecRef.NEXT = 0;

Система в этом случае валится через непродолжительное время.

Запустил этот код у себя на 5-ке (Build 25560, 26084 как у вас, под рукой не окзался) для 2 млн. записей: всё ОК, система не валится, так же ОК если не делать RecRef2.CLOSE (зачем вообще делать CLOSE если вы не делаете до этого OPEN?).
Что вы вообще потом делаете с RecRef2 после duplicate? Если хотите в цикле после каждого duplicate 100% очистить RecRef2, то сделайте просто CLEAR(RecRef2), и правильнее будет даже CLEAR сделать до duplicate.
Может у вас всё же в коде программа впадает в бесконечный цикл из за неложенных фильтров?
По поводу производительности: по-видимому в recref та же технология как и в темповых rec-переменных, у этих тоже с определённого числа записей производительность падает, т.к. темповые таблицы грузятся в память клиента.

Можно без close... Можно с CLEAR.
Но CLEAR до дупликейта не надо делать (да он и не поможет здесь), ровно как не надо делать CLEAR при COPY на таблицу - фильтры затрутся новыми...
В момент следующего дупликейта произойдет возврат нового рекрефа.
На RecRef ключ пробовали накладывать (скажем, по номеру счета)? По счету отфильтровали? В моей базе записей больше 10 млн. на всей 17-й. В отфильтрованном и отсортированном по правильному ключу наборе - порядка 2 млн. Пробуйте с ключом/фильтрами.

alexb_imported · 28.07.2012, 23:45

Цитата:

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

На RecRef ключ пробовали накладывать (скажем, по номеру счета)? По счету отфильтровали? В моей базе записей больше 10 млн. на всей 17-й. В отфильтрованном и отсортированном по правильному ключу наборе - порядка 2 млн. Пробуйте с ключом/фильтрами.

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

Romul · 29.07.2012, 07:50

Цитата:

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

Цитата:

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

На RecRef ключ пробовали накладывать (скажем, по номеру счета)? По счету отфильтровали? В моей базе записей больше 10 млн. на всей 17-й. В отфильтрованном и отсортированном по правильному ключу наборе - порядка 2 млн. Пробуйте с ключом/фильтрами.

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

Ну значит делаем неутишительный вывод - я лузер, чо.
А вообще - надо втупую разбираться с конфигурацией... Повторюсь - вся проблема в этом простейшем куске кода, который я привел. Утечка в дупликейте, а не где-то ДО или ПОСЛЕ...
В любом случае - спасибо, что попробовали. Плюсую за активность и интерес к проблеме

Alterant · 30.07.2012, 10:13

Цитата:

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

Цитата:

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

На RecRef ключ пробовали накладывать (скажем, по номеру счета)? По счету отфильтровали? В моей базе записей больше 10 млн. на всей 17-й. В отфильтрованном и отсортированном по правильному ключу наборе - порядка 2 млн. Пробуйте с ключом/фильтрами.

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

Расскажите, заодно, какой у вас билд. Сообщество должно знать о стабильных версиях.

alexb_imported · 12.08.2012, 20:31

Цитата:

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

Расскажите, заодно, какой у вас билд. Сообщество должно знать о стабильных версиях.

Build, на котором я тестировал, я уже сообщал в моём 1-м посте: 25560 (см. выше).

Цитата:

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

Запустил этот код у себя на 5-ке (Build 25560 ...

Я, честно говоря, сомневаюсь, что дело в Build'е.
Orwell, кстати, тестировал на более новом build'е 26084. Если у сообщества на build'e 26084 (которого у меня нет) тоже та же ошибка вылетает как и у Orwell, то тогда дело действительно в Build'е.

ОльгаМ · 31.10.2012, 13:34

Искала одну проблему, случайно зашла сюда.
Или я не совсем поняла, но почему DUBLICATE вы используете для каждой записи.
Пример:

RecRef.CLOSE; в 9-ой версии эта команда нужна.
RecRef.OPEN(17);
RecRef2 := RecRef.DUPLICATE;
MESSAGE('%1 - %2',RecRef.COUNT,RecRef2.COUNT);
DUBLICATE дублирует всю таблицу RecRef c фильтрами в табл.RecRef2, а не определенную запись.