Падает АОС с причиной "Недостаточно памяти"

[Corel]

Уважаемые, а не сталкивался ли кто с похожей проблемой? На ровном месте, при вполне достаточном количестве свободной памяти на сервере с разной периодичностью (от раз в неделю до двух раз в день) начали падать АОСы. Единственное сообщение, которое при этом выдаётся в лог - "Недостаточно памяти". Есть мысли, куда и как копать?


DAX 2009 3761

[Shirmin Oleg]

У нас если процесс Ax32Serv.exe подбирается к 1.1-1.2 Гб, то падает. Не зависимо от того, сколько свободной памяти на самом сервере.

[Corel]

Хм, ну да, примерно так и есть. А как уменьшить память, занимаемую им? Уменьшить количество подключений, добавив новые АОСы?

[Shirmin Oleg]

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

[Corel]

Хм, с сегодняшнего дня что-то изменилось и АОС упал с причиной Unexpected situation.

[IvanS]

АОСы отъедают память в момент построения перекрестных ссылок и компиляции, но почему-то потом её не возвращают. Поэтому поставили шедулер на перезапуск аосов утром

[gl00mie]

Цитата:

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

начали падать АОСы. "Недостаточно памяти". DAX 2009 3761

Цитата:

Сообщение от Shirmin Oleg

У нас если процесс Ax32Serv.exe подбирается к 1.1-1.2 Гб, то падает. Не зависимо от того, сколько свободной памяти на самом сервере.

Цитата:

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

Хм, ну да, примерно так и есть.

Если речь о 2009-й и падении при условии, что АОС отъел меньше 2-х гигов, то самое простое решение - использовать 64-битную версию АОС Из моего скромного опыта, она успешно работает, отъедая и по 8 гиг памяти. Правда, может потребоваться переписать кое-какие выполняемые на сервере модификации, если они используют WinAPI и/или сторонние DLL-ки (не касается .NET-сборок).
Еще из особенностей 2009: винды стараются кэшировать в памяти хоста АОСа файлы приложения независимо от того, расположены ли они локально или нет, на это могут уйти дополнительно 2-4 гига. Поэтому под рабочий хост АОСа 2009-й надо по возможности выделять не меньше 8 Gb памяти.
А вообще бывают случаи, когда АОС кратковременно отъедает слишком много памяти и падает из-за этого. Или даже когда на хосте АОСа какой-то другой процесс (например, другой АОС ) отъедает слишком много памяти, а АОС из-за этого падает. Имеет смысл поискать в system eventlog, скажем, сообщения от источника Resource-Exhaustion-Detector (как минимум в w2k8 r2 такой есть), непосредственно предшествующие падению АОСа.

[Maximin]

Бывают еще текущие (с memory leakами) версии АОСов. Советую обновлять версии выполнимых файлов из свежих хотфиксов (выходящих KB). Естественно, тестируя предварительно.
Еще рекомендую аккуратно работать с map и views на сервере. На моей памяти, код с этими интенсивно используемыми сущностями, приводил к "вздутию" АОСов чрезвычайно быстро.
После перекрестных ссылок и компиляции куча внутри АОСа жутко фрагментирована, видимо, сборщик мусора не так хорош, как мог бы быть. Перезапуск решает проблему на какое-то время (заодно чуть-чуть растет быстродействие, т.к. меньше накладных расходов на обслуживание фрагментированной кучи).

[Logger]

Цитата:

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

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

Можете что-нибудь посоветовать для решения проблемы ?
При сборе перекрестных ссылок по ветке аот - АОС уже дважды свалился в пакете.
Полагаю что либо не освобождает нормально treenode-ы либо map-ы раздулись.
Вообще странно конечно. Раньше такого вроде бы не замечалось за ним ( в 2009-й и 3-ке ).

P.S.
ax 2012 R3

[Corel]

Причиной падения оказался большой отчёт, собирающий данные в textbuffer для последующего вывода в Excel.
Поднятый на отдельной чистой машине (правда, слабенькой, запасной, с 4 гига общей оперативки) с win2k8 r2 64-битный АОС повёл себя точно также и вылетел по достижении 1.2 гига.
Отчёт переделали на вывод сразу в Excel, но, конечно, ситуация напрягает. Ладно, админы обещали обновить операционки на серверах, посмотрим, что будет после.