Мониторинг работы

[Logger]

Там лишние методы попались. Можно их закомментировать. Нужно лишь помеченное номером проекта R100701 и все. Замены тоже должны подойти кроме SysTreeNode::GRD_refreshAll4Com().
Box::yesNo_Net - заменить на Box::yesNo

При работе выглядит примерно так для пакетных обработчиков


Перевыложил проект.

[trud]

Цитата:

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

Перевыложил проект.

Столкнулись с такой проблемой - периодически какой-то пользователь(а может и пакетное задание) приводит к высокой загрузке АОСа 2009, сжирает всю память на аосе(16ГБ) и начинает создавать кучу временных таблиц на диске.
АОС при этом не падает, но начинает жутко тормозить. на SQL загрузки тоже особо никакой нет.
Стоит задача определить что это за пользователь(ну или что за пакет).
Я так понимаю приложенный проект как раз нацелен на это. Поскольку тема старая - может у кого нибудь есть свежие идеи(ну или обновления проекта) как найти виновника
Выглядит это приметрно так (версия 2009)

[Logger]

Цитата:

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

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

Мой пример был нацелен на то чтобы найти того, кто сожрал процессорное время. В части поиска виновника потребления памяти, мне кажется, он не поможет.

Есть другие способы, попозже опишу. Но гарантированного результата не дают.

[fed]

Цитата:

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

Столкнулись с такой проблемой - периодически какой-то пользователь(а может и пакетное задание) приводит к высокой загрузке АОСа 2009, сжирает всю память на аосе(16ГБ) и начинает создавать кучу временных таблиц на диске.
АОС при этом не падает, но начинает жутко тормозить. на SQL загрузки тоже особо никакой нет.
Стоит задача определить что это за пользователь(ну или что за пакет).
Я так понимаю приложенный проект как раз нацелен на это. Поскольку тема старая - может у кого нибудь есть свежие идеи(ну или обновления проекта) как найти виновника
Выглядит это приметрно так (версия 2009)
Вложение 12890

Я что-то такое видел, когда кто-то врубил EntireTableCache по часто обновляемой таблице. На SQL Server картина более или менее была (в целом - даже по таблице из 100000 записей выполнить select * from table не тяжело), но на AOSах творилось как-раз то, что у тебя описано. Один из AOS в кластере что-то в таблице обновляет, а другие видят какой-то семафор и бросаются таблицу читать с SQL и писать в временный файл. Попробуй посмотреть в кэше SQL Server, нету ли там каких-то загадочных (хотя и не очень затратных) полных селектов по таблицам, которые нету смысла целиком читать...

[Logger]

Цитата:

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

Я что-то такое видел, когда кто-то врубил EntireTableCache по часто обновляемой таблице.

И оперативная память тоже поглощалась ?
А это-то почему ? Не должна бы.

[fed]

Цитата:

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

И оперативная память тоже поглощалась ?
А это-то почему ? Не должна бы.

Ну вообще в моем случае, AOS в памяти рос, но не до таких размеров. Есть подозрение что там кто-то эдак на десяточек-другой популярных таблиц врубил EntireTableCache, и вся память отъедается на постоянно создаваемые курсоры.
Хотя - это и что-то другое может быть. Но у меня картина довольно однозначная была на AOS - при довольно таки плевых с прикладной точки зрения операциях, загрузка CPU выростала до 40-60 процентов при 5-7 параллельно работающих пользователях.

[Raven Melancholic]

Цитата:

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

Ну вообще в моем случае, AOS в памяти рос, но не до таких размеров. Есть подозрение что там кто-то эдак на десяточек-другой популярных таблиц врубил EntireTableCache, и вся память отъедается на постоянно создаваемые курсоры.
Хотя - это и что-то другое может быть. Но у меня картина довольно однозначная была на AOS - при довольно таки плевых с прикладной точки зрения операциях, загрузка CPU выростала до 40-60 процентов при 5-7 параллельно работающих пользователях.

Вспомним историю:
формальные показатели включения cacheLookup EntireTable

[trud]

Цитата:

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

Ну вообще в моем случае, AOS в памяти рос, но не до таких размеров. Есть подозрение что там кто-то эдак на десяточек-другой популярных таблиц врубил EntireTableCache, и вся память отъедается на постоянно создаваемые курсоры.

Бинго .

Спасибо, я как-то упустил этот момент. Но хочется отменить что современные сервера стали быстрее, тут система как-то дожила до 1млн записей.
Джоб для проверки(https://github.com/TrudAX/TRUDScript...re-table-cache ,проверьте свои системы

[Raven Melancholic]

Цитата:

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

Бинго .

Ух ты, а что за бизнес-ситуация при которой в InterCompanyEndpointActionPolicyTransfer такое количество записей?