Показать сообщение отдельно
Старый 21.01.2020, 16:29   #22  
FrolovAndy is offline
FrolovAndy
Участник
 
71 / 45 (2) +++
Регистрация: 13.09.2007
Попробую сразу в одном сообщении ответить на всё.

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

Пытаться перекидывать на другой АОС будет проблематично. У нас специфика, использование Workflow стандартного, и для него важно чтоб на машине где крутится АОС, была обеспечена вся необходимая инфраструктура. Выделять ещё один АОС - это означает проделывать ещё раз все действия для обеспечения работы Workflow, и поэтому у нас на такой шаг пойдут в последнюю очередь. Собственно, из-за этого даже пакетные обработки по WF крутятся на основном АОСе, по этой же причине что на пакетном сервере не хотят устанавливать WF. Иначе было бы здорово, как раз по одному переводить на пакетный АОС и наблюдать за изменениями в памяти, но никак.

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

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

С другой стороны, когда я смотрю на то что происходит в рабочей среде, там нет каких-то мощных темпов расходования памяти, она просто плавно уходит, и не возвращается
И вот я попробовал поэкспериментировать на тестовом, уже не запуском замысловатых алгоритмов, а просто как пользователь - открываю-закрываю формы, какие-то отчеты запускаю, действия выполняю... И вот что интересно - именно при такой работе у меня тоже пошла уходить память понемногу, но безвозвратно. Не скажу что большой расход, но я по себе прикинул что если помножить это на количество пользователей и на количество рабочих часов, то в сумме как раз и будет та самая утечка
То есть что-то происходит на обычном уровне использования системы такое, что уводит память безвозвратно. Не какой-то глючный алгоритм в отдельно взятом месте, а просто обычный рабочий процесс. Это больше наталкивает на мысль о глюке в интерфейсной части.
Ведь опять-таки - отдельно выделенный пакетный АОС утечек не создает. В то время как на нем много чего крутится, различного функционала. Казалось бы там еще больше должно расходоваться. А дело видимо в тех процессах которые отвечают конкретно за уровень взаимодействия с пользователем. Может и обновить что-то надо, а может где-то некорректно допилили какую-то общеиспользуемую штуковину типа SysSetupFormRun или что-то около того где интерфейс обеспечивается, в общем других вариантов пока для себя не вижу кроме как зайти теперь с этой стороны

P.S. SysHeapLog не помог каким-то ощутимым образом. Может у него где-то есть какие-то особенные возможности о которых я не знаю, но то что удалось вытащить с его помощью это общая информация с помощью которой всё равно непонятно где копать. Либо я плохо с ним разобрался