Пользователь
Логин:
Пароль:
Забыли свой пароль?

Поиск по сайту
 

 Расширенный поиск
Реклама

 

Опрос


Погода

Салават Арипов (все сообщения)
Форумы
Обновления
Поиск
Пользователи 
Правила
Помощь
Войти

Выбрать дату в календаре ...  Выбрать дату в календаре

Страницы: Пред. 1 2 3 4 5 6 7 8 9 10 11 След.
Как написать свой патч для OVSD 4.5 или Client 2008
#
09.09.2011 13:37:44
Цитата
Григорий Ненашев пишет:
Можно пойти другим путём.

Пишем бантик на срубание процесса, далее, через GPO распространяем всем специалистам, кто пользуется SD. (в task) B час X он закроет всем клиента.



И делаем запрет на удаление, данного таска.


Не всё так просто - у нас куча филиалов, у каждого свой домен, GPO писать нужно для каждого тогда, соответственно, согласовывать с ИТ-начальством каждого филиала. Гемморой, короче. А если нужно, к примеру, выключить именно сейчас, в данный момент?

Цитата
Валерий Квертовский пишет:
Цитата
Салават Арипов пишет:

Если придумаете как при помощи класса заставлять пользователей выходить из SD, буду признателен


А в чем проблема? Мы с клиентом целый день работаем. На ночь нельзя оставлять включенным?


Да, часто делаются какие-нибудь мелкие доработки по просьбе департаментов, которые срабатывают в UI-интерфейсе, а люди НЕДЕЛЯМИ не выходят из программы. Соответственно, до них эти доработки/изменения не доходят.
 
Перейти
Как написать свой патч для OVSD 4.5 или Client 2008
#
09.09.2011 12:42:50
Если придумаете как при помощи класса заставлять пользователей выходить из SD, буду признателен smile:)
 
Перейти
Кто повесил систему?
#
30.08.2011 09:31:58
Цитата
Григорий Ненашев пишет:
Да это я уже давно юзаю, причем 3000 элементов максимум…

Наверно я так и сделаю последний запрос… в отдельную таблицу копировать буду… вот только не создаст ли это еще большую нагрузку на систему…..как думаешь?

Доброе утро, Григорий! Вы реализовали запись последнего запроса в таблицу? Если не трудно, не могли бы подсказать как - может и мне поможет с моей проблемой...
 
Перейти
Создание инцидента с помощью sd_event, sd_event
#
26.08.2011 12:59:58
Цитата
alexx2xx ivanov пишет:
Да, извиняюсь, это просто ID инцидента. Event_ID маппится как Source ID, я подумал что это именно он и есть.



А параметры для event_id где нибудь определяются (формат и т.д.)?

В мэппинге посмотрите, скорее всего обычное текстовое поле длинной в 255 символов.
 
Перейти
Зависание SQL сервера.
#
07.09.2011 10:58:34
Цитата
Григорий Ненашев пишет:
itsm_historyline_servicecall Я про эту таблицу.



Есть еще такая мысль, а что если на SQL удалить все учетные записи, которые имеют права использовать ресурс самого сервера.(Кроме app серверов SD) Может это не Service Desk вызывает данный провис, а какой-то скрипт, который лезет в базу за данными и много поточным запросом вытаскивает данные. Кстати на момент 1000 сессий как себя чувствует CPU сервера?

В целом, неплохо - до 100% не доходит. Вот график поведения загрузки перед зависанием
Рисунок
1.PNG (147.88 КБ) [ Скачать ]
 
Перейти
Зависание SQL сервера.
#
07.09.2011 10:07:28
Цитата
Григорий Ненашев пишет:
Еще чистка журнала обращений тоже помогает.

В смысле historylines или архивирование самих SC? Историю подчистил тоже, из 30 млн. записей осталось не более 7 млн.
 
Перейти
Зависание SQL сервера.
#
07.09.2011 10:04:20
Цитата
Григорий Ненашев пишет:
Проходил я через все это уже…

Это не поможет, проблема в другом. Отключение вкладки email поможет + очистка данной таблицы.

Но у вас же висло на короткий промежуток времени, а затем всё снова работать начинало. То есть, по сути, были тормоза системы. У меня виснет наглухо - просто не принимаются новые сессии в SQL, а потом начинают отваливаться сессии, которые уже были подключены. Да и сам сервис SQL не рестартуется - консоль виснет, перезапуск возможен только путём "убивания" процесса через диспетчер задач. Да и отключил я всем доступ к e-mail SC, таблицу почистил хорошенько (осталось около 300 тысяч записей только). В любом случае, начальство запретит мне, без веских оснований, отключать эту функциональность, уже спрашивал.
 
Перейти
Зависание SQL сервера.
#
07.09.2011 09:50:13
Цитата
Григорий Ненашев пишет:
Зависания все продолжаются? Или все-таки нашли истинную причину зависонов?

Продолжаются. Сейчас отключил всем возможность создавать свои вьюхи, хотя надежды мало, что это от них.
 
Перейти
Зависание SQL сервера.
#
29.08.2011 12:17:37
Цитата
Василий Каменев пишет:
не, spot мониторит сессии скула. 1000 это круто, апп сервера столько не сделают, а если делают, то есть явно проблема с сессиями на лицо!!

по умолчанию у апп сервера стоит 16 сессию на, если включены "репы", то ещё добавится 6, итого 22. больше сервер не поднимет сессий в sql сервер.

посмотри свои настройки и посчитай по серверам сумму сессий, всё что больше - левые, либо падает нет и они зависаю, либо просто зависаю а сервер делает рестарт, либо их создает др. софт вообще.

Ну здесь у меня сейчас тоже стоит 6/16, просто ранее Григорий писал:
Цитата
Григорий Ненашев пишет:
Так это же коннекты апп серверов… Следовательно можно предположить, что это нагрузка на сам SD возрастает, вот он и начинает плодить сессии.

А так 10 APP-серверов дают 160 коннектов. То есть, более этих 160 быть от SD и не может?
 
Перейти
Зависание SQL сервера.
#
29.08.2011 10:46:31
Цитата
Василий Каменев пишет:
это сколько серверов надо иметь чтоб то 1к поднять?! если на один аплик сервер даже поставить 50(хотя это слишком много для одного), то получим 1000/50 = 20,0. так что реально 20 аплик серверов?

Я имел в виду не сессии пользователей, а коннекты к БД. Вот картинка со спотлайта. По ней видно, что 2 дня (рабочих причём) коннекты держались на низком уровне, а потом снова взлетели вверх. Так вот и вопрос - возможно ли это по вине пользователя, неудачно настроившего, к примеру, представление (добавил какие-либо столбцы, группировки и т.д.)?
Рисунок
1.PNG (34.28 КБ) [ Скачать ]
 
Перейти
Страницы: Пред. 1 2 3 4 5 6 7 8 9 10 11 След.

Сегодня были (гостей: 9, пользователей: 0, из них скрытых: 0)