Как мониторить нагрузку на базу 1С в разрезе пользователей

[parahumanoid]

Возможно, вопрос из области фантастики, но:

Как я могу видеть какая инстанция входа в 1С нагружает на данный момент сервер? Кто-то повадился "тяжелые" проводки катать среди бела дня, хочу изловить негодяя. У нас такие операции в спец. часы положено проводить.

[DmitryE777]

Журнал в 1С - и в нем отловить кто проводки делал в неурочное время.

[parahumanoid]

Журнал в 1С - и в нем отловить кто проводки делал в неурочное время.

А что журнал? Допустим, оператор запускает обработку массового проведения заявок/накладных или чего там. Ну и как эти накладные должны выпячивать на фоне остальных, введенных в непакетном режиме? Мне надо увидеть кто грузит систему именно в реальном времени. Хотя бы какой пользователь винды или какая учетка 1С. Там уж дальше откопаю. Но стандартные счетчики производительности ОС показывают только общую нагрузку. Вот я вижу, что перегружена очередь дискового массива, и даже догадываюсь, что эту нагрузку дает SQL server, а тот в свою очередь обрабатывает запросы привязанной к нему 1С 7.7. Но какие именно пользователи среди 35 одновременно запущенных сессий 1С делают это, мне не видно. И тот факт, что все работают в терминальном режиме, тоже жизнь не облегчает, так как даже в режиме монитора, все учетки 1С числятся как зашедшие с одного и того же ПК.

Может, хоть MS SQL содержит оснастку для оценки текущей нагрузки? Хотя какая разница для 1С? Все равно все юзеры 1С вяжутся на базу под одной учеткой - "sa". Может, еще идеи есть, или я не совсем понял Ваш подход?

[DmitryE777]

Может, еще идеи есть, или я не совсем понял Ваш подход?
Ну начать с того, что у вас вдруг и внезапно появляются еще дополнительные условия. Вроде MS SQL и 7.7 (а не 8.2).
Максимум что вы в таких условиях можете сделать - любым инструментом вроде Диспетчера Задач или Anvir Task Manager попытаться в реальном времени вычислить юзера, максимально нагружающего память-проц-винт. Всё. На этом набор инструментов исчерпан.

[sskkru]

Если 1С не dbf-вариант, то мониторить можно через менеджера соответствующего движка СУБД (например, для MS SQL это Enterprise Manager)

[SergeyST]

Это конецно зависит от специфики выполняемых операций, но практика показывает, что в большинстве случаев тот пользователь, процесс которого грузит СКУЛЬ запросами, а тот в свою очередь диски и всё остальное, имеет в деспечере задачь какую-то активность, пусть даже 1-2 %. Бывает достаточно понаблюдать внимательно за нагрузкой (35 пользователей = это наверное тяжко будет :) ) процессов 1С и возможно вычислить "негодяя"

[parahumanoid]

Если 1С не dbf-вариант, то мониторить можно через менеджера соответствующего движка СУБД (например, для MS SQL это Enterprise Manager)

Вопрос, в общем-то пока практически отпал, но в принципе остается в силе. Дело в том, что т.к. все копии 1С запущены на одной машине, только в разных сеансах, то не вижу как мне Enterprise Manager отобразит виновника, если он теряется в общей каше. Адрес подключения-то у всех одинаковый. Единственное, что как мне *кажется* могло бы послужить ниточкой в этом вопросе - это номер ТСP сессии, но я себе не представляю как даже в теории Скуль может видеть номер клиентской сессии, ведь для него даже локалхост - это удаленка. Всё было бы проще, если бы 1С 7,7 поддерживал подключения под разными юзерами Скуль, но увы. Подавай одного, да еще и вдалельца базы - не меньше.

Может, я что-то упускаю? Можете описать use-case? Терминал с множеством 1С и на этой же системе Скуль (я знаю, что это не лучшее решение на одной системе их гонять, но сейчас речь не о том).