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

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

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

 

Опрос


Погода

Салават Арипов (все сообщения)

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

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

Страницы: Пред. 1 2 3 4 5 6 7 8 9 10 11 След.
Зависание SQL сервера.
Цитата
Григорий Ненашев пишет:
Цитата
Салават Арипов пишет:

>>Каждый апп сервер разнесен на части? Скажем, они пронумерованы




я про это.

Код
<PROPERTY NAME="METRICSPORT">6001</PROPERTY>


Может, какие триггеры вешают базу? (если они есть..)

Лично я бы все-таки, для начала отключил логирование почты. И посмотрел бы, как себя начнет чувствовать база…

Хмм, я даже не знал, что нумеруется именно так. Я так понимаю, нужно для каждого app-сервера прописать свой 6001, 6002...6xxx?
Насчёт почты - попробую, если совсем ничего не поможет - EmailSC всё-таки очень нужная вещь, с учётом того, что мне часто приходится доказывать различным людям, что письма им-таки уходили. А триггеров нет, как-то делал парочку, но отказался от них по причине блокировок таблиц и, соответственно, косяков, связанных с этим.
Зависание 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% увеличилась нагрузка.
Изменено: Салават Арипов - 12.08.2011 13:05:06
Зависание SQL сервера.
Есть мысль, что коннекты перестают создаваться из-за достижения верхней планки памяти (судя по спотлайту). Возможно, есть мёртвые коннекты, которые по каким-то причинам не отвалились.
Зависание SQL сервера.
Цитата
Василий Каменев пишет:
а какой размер лога транзакций?

Небольшой (обычно не более 2 Гб), так как бэкапится ежедневно.
Зависание SQL сервера.
Цитата
Василий Каменев пишет:
что будет(ло), если в этой ситуации перезагрузить апп сервер,поднимется ли и позволит ли работать с клиентом?



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

у вас скул с какой лицензией, не cpu?

Если перезапустить сервисы SD, то да, они не увидят базу и в логах будет ошибка о том, что новых сессий быть не может. Насчёт лицензии - она у нас Enterprise, поэтому, полагаю, ограничений быть не должно.
Зависание SQL сервера.
Поставил "Spotlight on SQL Server". Перед тем, как SD снова перестал работать, Spotlight перестал собирать данные. В течение ещё минут 40 вход в SD, работа с заявками и прочее было возможным. однако зайти на БД не представлялось возможным, как и выполнение каких-либо job-ов. Затем помер и сам Service Desk. Прилагаю файл со спотлайта, может вы увидите проблему?
Рисунок
1.PNG (89.04 КБ) [ Скачать ]
Зависание SQL сервера.
Цитата
Григорий Ненашев пишет:
Цитата
Салават Арипов пишет:

E-mail ServiceCalls использую, записей там что-то около 3.5 млн




Имея опыт с этой таблицей, я бы удалил все, что там есть! СПАМ, т.е информационные письма. (но если удалять нельзя, то нужно заказывать доработку системы т.к, на сколько я помню, Василий поправит если я не прав, то данная вкладка работает коряво и ее нужно дорабатывать.) – у меня из-за нее были жуткие проблемы все висло каждые 2-3 часа на 3-4 мин.

Также был большой объем данных в данной таблице.

Насколько я понимаю, задумчивость у вас происходила из-за большого потока писем? У меня мало заявок регистрируется через e-mail, менее 10% от общего числа заявок, в основном регистрация идёт через сильно переделанный web-интерфейс.
Зависание SQL сервера.
Цитата
Василий Каменев пишет:
если всё раньше было "красиво и пушисто", то вернитесь к моменту когда всё началось. попытайся найти что изменилось в окружении: меняли хардвер, поставили пак на винды, запустил новый рапорт, СД перевёл на новый пак и т.д. иногда помогает выявить причину, тогда легче фиксить.

Пробовал убирать надстройку, сделанную в апреле, не помогло.
Зависание SQL сервера.
Цитата
Григорий Ненашев пишет:
Какие ни будь плановые работы над базой проводите каждый день?: «Переиндексация, оптимизация?»

В том-то и дело, что нет. Переиндексацию и сжатие делаю раз в месяц, причём достаточно давно уже.


Цитата
Григорий Ненашев пишет:
По поводу разбития базы я подразумевал использования «Папок» - И ограничение по ролям на каждую папку. Например зачем лазить в SC за 2006-2009 год. Ставим папку Архив и никто в ней ковыряться кроме тех кому дозволенно не будет.

Да, по папкам есть ограничение у множества ролей (некоторым жизненно необходимо видеть все заявки, которые они пожелают, но как я и писал выше, в поиске всё равно стоит ограничение на 3000 элементов)


Цитата
Григорий Ненашев пишет:
Такой еще вопрос вкладу Email используете? Если да то сколько объектов в данной таблице?

E-mail ServiceCalls использую, записей там что-то около 3.5 млн

Цитата
Григорий Ненашев пишет:
Еще такая мысль… а может базу кладет какое правило? Или job… если есть… нужно все –таки искать истинную причину … может быть диск захлебывается? Очередь к диску смотрели на момент сбоя?

Смотрел все основные показатели во время зависания - практически ничем не отличаются от обычного состояния. В качестве дисков у нас блэйды, вряд ли они могли захлебнуться. Грешил на правила, заблокировал всё, что было сделано в апреле месяце (надстройка достаточно существенная - внешние запросы, писанные в jsp, в которых в том числе и SQL запросы имеются), на пару недель зависоны прекратились, а потом начались снова.

Цитата
Григорий Ненашев пишет:
8 ГБ для базы в против 40 ГБ на мой взгляд это мало… можно еще посмотреть сколько он памяти отъедает.. может ему не хватает, у меня такое было… сейчас 32ГБ вроде живет… (Правда симптомы должны быть немного другими… когда не хватает памяти, то он начинает процессор кушать, а тут 10%... но все равно проверить стоит)

Не думаю, что это настолько критично, раньше вообще без AWE обходились (подтупливал чуть больше, чем сейчас, но не намного).
Зависание SQL сервера.
Цитата
Григорий Ненашев пишет:
Не пойму.

Цитата
Салават Арипов пишет:

Блокировки тоже смотрел – отсутствуют

присоединиться к ней невозможно вообще, ни через SD, ни напрямую через менеджмент студио




А как смотрели?



Отвисает или приходиться сервер перезагружать? Как оживляете базу?

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

Базу били на куски? Может кто-то по всей базе шуршит…

Какая нагрузка на SQL?

Смотрел стандартным средством сиквела - activity monitor
SQL приходится перезапускать (иногда даже убивая процесс sqlservr.exe - на стопе сервиса также бывают зависания). Сам sql грузит систему несильно, в режиме AWE ограничил его 8 Гб памяти, процессоры редко выше 10% загружаются.
Базу на куски не бил, расскажите поподробнее, пожалуйста.
Страницы: Пред. 1 2 3 4 5 6 7 8 9 10 11 След.

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