Зависание SQL сервера.

Цитата

Григорий Ненашев пишет: У меня такой вопрос возник, а не настроена ли какая либо синхронизация? Скажем, кто-то может послать прямой запрос к базе, или, есть 2 SQL сервер который забирает накопившееся транзакции и подкладывает их к себе, может какой JOB настроен на каждые 2-3 часа что-то выполнять? Еще вопрос, сколько стоит тайм аут на отключение неактивных сессий? И какое ограничение установлено для app сервера открытия сессий? И какой поток установлен для 1 сессии? Каждый апп сервер разнесен на части? Скажем, они пронумерованы? Василий правильно вопрос поставил. Цитата Василий Каменев пишет: если всё раньше было "красиво и пушисто", то вернитесь к моменту когда всё началось. попытайся найти что изменилось в окружении: меняли хардвер, поставили пак на винды, запустил новый рапорт, СД перевёл на новый пак и т.д. иногда помогает выявить причину, тогда легче фиксить Нужно понять, после чего начались такие проблемы, какие действия предшествовали появлению проблеме, На моей практике, если сначала обкатали обновления на тестовом стенде, проблем не было выявлено, в production перенесли, только через 7-10 дней вылезла ошибка, которую заметили специалисты 2 линии. Скажем банально срок по 1 шаблону считаться неправильно. Если память забивается на SQL, то самый простой способ это посмотреть, кто ее отъедает. Если это SQL, то нужно добавлять ему память, есть конечно же еще подозрение, что у Вас это волновой эффект, когда все было хорошо при этом ничего не трогали, а только плодили нагрузку, и не углядели за показателями роста… вот и вылезла болячка….

Синхронизаций достаточно много, с различными системами. Но они происходят, в основном, раз в сутки и те ночью. Job-ы тоже все пересмотрел по нескольку раз. Тяжёлого на боевой базе они не выполняют, поэтому вряд ли могут сильно отъедать память. "Отъедание" происходит именно в рабочее время (прям на графике чётко видно, что с 6 вечера до 6 утра память держится на одном уровне, а потом начинает расти.
>>Еще вопрос, сколько стоит тайм аут на отключение неактивных сессий? И какое ограничение установлено для app сервера открытия сессий? И какой поток установлен для 1 сессии?
Таймаут на сессии ставил разный - от 300 до 900 секунд (SQL), на серверах приложений таймаут 90 минут, особого изменения режима "падений" не заметил. Для Application серверов устанавливал также различные количества сессий и потоков. На данный момент такая конфигурация:
REPO MAXIMUM POOLSIZE = 23
REPO MINIMUM POOLSIZE = 12
THREADPOOLSIZE = 60
>>Каждый апп сервер разнесен на части? Скажем, они пронумерованы?
Да, app сервера пронумерованы, сервисы проинсталлированы различные.
>>Нужно понять, после чего начались такие проблемы, какие действия предшествовали появлению проблеме
Пытаюсь разобраться, что именно могло привести к этой ситуации, вроде даже удалял все новшества, введённые в апреле, но всё безрезультатно.
>>Если это SQL, то нужно добавлять ему память, есть конечно же еще подозрение, что у Вас это волновой эффект, когда все было хорошо при этом ничего не трогали, а только плодили нагрузку, и не углядели за показателями роста
Эти показатели тоже смотрел, сильных скачков не было, максимум на 10% увеличилась нагрузка.

Цитата
Григорий Ненашев пишет: Цитата Салават Арипов пишет: >>Каждый апп сервер разнесен на части? Скажем, они пронумерованы я про это. Код <PROPERTY NAME="METRICSPORT">6001</PROPERTY> Может, какие триггеры вешают базу? (если они есть..) Лично я бы все-таки, для начала отключил логирование почты. И посмотрел бы, как себя начнет чувствовать база…

Хмм, я даже не знал, что нумеруется именно так. Я так понимаю, нужно для каждого app-сервера прописать свой 6001, 6002...6xxx?
Насчёт почты - попробую, если совсем ничего не поможет - EmailSC всё-таки очень нужная вещь, с учётом того, что мне часто приходится доказывать различным людям, что письма им-таки уходили. А триггеров нет, как-то делал парочку, но отказался от них по причине блокировок таблиц и, соответственно, косяков, связанных с этим.

Я тут всё смотрю на различные показатели, меня насторожили всплески сессий. Я предполагаю, что быть такого не должно...

Цитата
Григорий Ненашев пишет: Так это же коннекты апп серверов… Следовательно можно предположить, что это нагрузка на сам SD возрастает, вот он и начинает плодить сессии. THREADPOOLSIZE = 60 - не многовато ли? Сколько в online пользователей работают в системе?

Только вот эти коннекты и сегодня около 9 утра вылезли за тысячу, сомневаюсь, чтобы столько пользователей захотело выйти в выходной поработать.
Насчёт THREADPOOLSIZE - было 25, SD клиент подтормаживал при обновлении списка заявок.