Галактика в вопросах и ответах

Возможно ли как-то отследить какой пользователь в данный момент времени больше всего "нагружает" первасив? Используем первасив 2000 с сервиспаком 2а. Монитор первасива в этом никакой пользы не оказывает. А ведь не секрет, что существуют такие галактические операции/отчеты/запросы которые могут очень сильно "тормозить" работу системы. Как узнать какой пользователь "затормозил" работу Галактики? Может у кого-то есть какие-то наработки по этому вопросу?

Не вполне понятно каким образом сервер может кто-то из клиентов сильно затормозить...Еще когда была BTRIEVE-вскоая Галка то никогда процессор не был загружен более чем на 5-10 %.А сейчас вообще на 2-3 %(MSSQL). Позапускай разные отчеты и увидишь, что на клиенте камень загружен весьма изрядно, т.е. практически вся логика программы на локале отрабатывает.Да и зачем тебе это нужно ? Ну узнаешь кто больше нагружает...отчеты что ль все переписать хочешь ? Главный показатель для Г, по моему убеждению, это объем оперативной памяти, винты пошустрее, и "дырдочка" сетевая побольше - т.к. на стороне сервера идет лишь активное считывание/запись информации с винчестера и обмен между клиентом и сервером. И никакой бизнес-логики там нема.
Файл-сервер короче...

можно вообще обойтись без всякого мониторинга
в момент когда гала просаживается смотришь в журнал и видишь кто из пользователей сильно садит. Один из критичных режимов пакетное формирование счетов фактур - туда компик нужно помощнее и памяти поболе. + таже журнализация тормозит - нужно в этот момент посмотреть какие таблицы усиленно юзаются и их по возможности убрать.

По журналу нифига не видно. В системе работает 50-60 пользователей которые интенсивно вносят изменения. Около 30 человек одновременно формируют ДО, накладные, ордера, прием спецификация док-та в среднем 500 позиций. Плюс бухгалтерия с проводками. актами, справками и т.д.
Что-то увидеть в журнале - не реально. Суточный объем записей в журнале около 1,5 миллионов.

Для Den.
По поводу "мнимого" клиент-сервера согласен - в реальности это больше напоминает файл-сервер. Но что все-таки делать? Отчеты/запросы которые "вешают" систему существуют. И в момент работы корпо-обмена могут приводит к такому "ступору" системы...!!!Тот же отчет "Реализация товаров оказание услуг", после закрытия окошка с полученным отчетом (уже после просмотра и печати!!!) система "отдыхает" до 20мин.!!!(в зависимости от периода отчета). Вместе с корпо-обменом некоторые отчеты приводят к огромному замедлению работы системы. Рабочая база галактики содержит информацию о движении за 1 год и имееет размер 36Г. Сервер HP с четырмя ксеонами по 500МГ, оперативная память 2,5T, сеть 100 мегабитная. Все нормально работает пока кто-то не зарядит такой отчетик. "Убиваешь" пользователя - все опять отлично. Так что проще? - апгрейдить систему, выбрасывая кучу бабок? или же "ограничить" работу таких пользователей в часы пик перенеся эти операции на менее загруженное время? Пользователей в системе около 60, на разных этажах здания, за всеми не уследишь. Странно что ни у кого не возникало таких проблем.

Вариант - переписать самому нужные отчеты, которые не устраивают пользователей по каким-то параметрам...

Сколько весит журнал?

Размер журнала в районе 1,3G. Срок хранения записей установлен 1 день.
У нас есть в планах апгрейд сервера, разнесение "жирных" таблиц по разным серверам, секвестирование базы и др. варианты. Но на реализацию их потребуется время, а проблема загрузки становится все острее. Спасибо всем кто откликнулся на мой вопрос.

Попробуй ограничить кол-во журнализируемых таблиц.

Предыдущий совет очень дельный.
Мы начинали с журналирования всей базы - тормоза были жуткие. Сейчас журналируем только несколько важных таблиц, что меня как администратора не устраивает конечно, но что делать...

Кроме того, можно подумать о смене платформы - на Оракле отчеты крутятся куда как быстрее.

Что-то тут не так. Если все так, как ты описываешь, то имеем:
1. Годовая база 36 гигов, если взять для упрощения модель, что заполнения базы идет равномерно, то один месяц - 3 гига, один день - 3 гига / 21 (среднее кол-во раб дней в месяце за вычетом выходных) = 146,3 метров в день.
2. Журнал хранится 1 день и объем его 1.3 гига, т.е. получаем, что на 146.3 метров внесенной информации журнал составлят 1.3 гига? При этом пускай пользователей всегда 60, тогда имеем, что один пользователь внес данных на 2,438(3) метра, и при этом часть журнала на него относится на 22,186(6) метров?

Такое возможно, только если вы каждый день запускаете какие-либо массовые пересчеты, т.е. к примеру закрытие периодов, расчеты зарплаты и т.д.

Может действительно у вас журнал растет на 1.3 гига в день, но тогда объясните за счет чего?

Люди!
А поделитесь опытом частичной журнализации
Какие таблици журнализируются обязательно, а от каких можно отказаться
Было бы очень интересно ....

>> один пользователь внес данных на 2,438(3) метра, и при этом часть журнала на него относится на 22,186(6) метров?

А почему нет? На одну операцию вставки записи в БД приходится куча операций модификации с этой записью.
Кроме того, часто пользователь что-то сделает, потом кучу раз это поправит, затем все это удалит и переделает с "нуля". Журнал-то расти при этом должен.

>> Какие таблици журнализируются обязательно, а от каких можно отказаться

Это зависит от важности таблицы
Я, например, среди прочих OBOROT отслеживаю - кто-нибудь грохнет проводку - ищи потом виноватых...

>>..пользователь что-то сделает, потом кучу раз это поправит...
Так и есть. Кроме того, размер файла журнала говорит о его максимальном заполнении (когда-то своевременно не запустилась процедура сжатия журнала или день на "модификации" выдался прибыльным). Фактически внутри журнала может быть и не большое кол-во записей, однако из-за размера файла скорость работы замедляется. Кстати, на днях сделал ребилд журнала и корпо-таблиц. Размер этих таблиц уменьшился и скорость работы заметно возросла.