Комментарии 8
Вот так метрики производительности собираешь, мониторишь, ищешь проблему… а там оказывается в просто внутри обработки или конфигурации нахламокожено и оно не может не тормозить, потому что пол базы вычитывает при каждом движении и сама себе блокировки таблиц накидывает побольше.
… но виноваты по дефолту админы.
Могу только добавить, что собирать метрики в отрыве от пользовательских сессий 1С и регламентных заданий можно, но этого недостаточно поскольку трудно будет провести корреляцию событий. Даже один бухгалтер использующий обработку с корявым кодом может легкими движениями раздувать базу(ы) TempDB с шагом в пару гигабайт в минуту до пары сотен гигабайт.
… но виноваты по дефолту админы.
Могу только добавить, что собирать метрики в отрыве от пользовательских сессий 1С и регламентных заданий можно, но этого недостаточно поскольку трудно будет провести корреляцию событий. Даже один бухгалтер использующий обработку с корявым кодом может легкими движениями раздувать базу(ы) TempDB с шагом в пару гигабайт в минуту до пары сотен гигабайт.
Язык не повернется поспорить.
Но!
Чтобы припереть программиста к стенке как раз и нужно собирать метрики.
Этими мы понимаем что что-то произошло нехорошее, а логами ТЖ или тем же профайлером находим кто накосячил.
Это пока за пределами публикации но вполне реализуемо
Ну раз вы дополнили комментарий, то и я допишу свой )
Совсем трудно будет провести корреляцию событий
Клянусь своей треуголкой.
Тот же профайлер интегрируется со счетчиками perfmon и вы в 60 сек поймете кто что и зачем делает.
Будет интересно — голосуйте, напишу)
Но!
Чтобы припереть программиста к стенке как раз и нужно собирать метрики.
Этими мы понимаем что что-то произошло нехорошее, а логами ТЖ или тем же профайлером находим кто накосячил.
Это пока за пределами публикации но вполне реализуемо
Ну раз вы дополнили комментарий, то и я допишу свой )
Совсем трудно будет провести корреляцию событий
Клянусь своей треуголкой.
Тот же профайлер интегрируется со счетчиками perfmon и вы в 60 сек поймете кто что и зачем делает.
Будет интересно — голосуйте, напишу)
Думаю очередная статья про event collector.
А тут даже проще.
Собирайте всё в elasticsearch.
События системы/метрики + экспорт из журнала 1с.
Дальше будет видна корреляция между действиями в 1с и нагрузками на сервер.
Perfmon -> MetricBeat (собирать метрики Windows, SQL)
ТЖ -> Любые статьи в гугле «1С elasticsearch»
EventLog -> WinLogBeat (собирать события входа на RDP сервер)
Импорт в elastic порождает довольно много трафика, это может серьезно сказаться если сбор данных идет с удаленного сервера через vpn канал.
Если не настроить фильтрацию перед загрузкой в ELK, то дискового объема нужно будет очень много.
ТЖ -> Любые статьи в гугле «1С elasticsearch»
EventLog -> WinLogBeat (собирать события входа на RDP сервер)
Импорт в elastic порождает довольно много трафика, это может серьезно сказаться если сбор данных идет с удаленного сервера через vpn канал.
Если не настроить фильтрацию перед загрузкой в ELK, то дискового объема нужно будет очень много.
Любые статьи в гугле «1С elasticsearch»
Про это я в курсе
Но там в основном мониторят ошибки по ТЖ
Это легкий журнал
А если попытаться такой связкой понять кто ставит колом сервер своими запросами, то это во первых будет очень тяжелый ТЖ, а во вторых сбор такого ТЖ сам по себе не хило тормознет сервер и в третьих из него не факт что легко выйти на нагрузку, потому как в базе 500 человек а в ТЖ только время и длительность события
Поэтому таких статей в гугле не найдешь
Поэтому жду от вас пруф
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Настройка сборки данных в Performance Monitor Windows Server