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

[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 такое количество записей?