MS SQL server стал совсем "экономичным"

1. Besica ™ (besica) 10.01.17 09:22 Сейчас в теме
Процесс сервера SQL в диспетчере показывает что использует он всего 200 - 220 мб оперативы, Сервер 32 гб. оперативы, настроен на использование до 20 гб оперативы. SQL server и 1С Сервер на одной машине.
Обычно он был вполне таки прожорливым и съедал много.
База порядка 100 гб. - почти 24/7 - но максимальная нагрузка в рабочие дни.
В первый рабочий день сервер начал долго думать - сначала искали какие то тяжелые запросы - но по данным SQL он не был "загружен" работой - а точнее практически простаивал.
rphostы кушали по 1,5 ГБ оперативы и пытались кушать дальше.
В момент выпадания сервера была только ошибка в 1с "Программа 1CV8C.exe версии 8.3.7.2008 прекратила взаимодействие с Windows и была закрыта."

В принципе все работает - и отчеты формируются и даже большие (хотя возможно и медленнее чем обычно - 1С замеров пока не делали) - НО растут только rphost - sql сервер "свободен", и сейчас понятно что процедура падения сервера сегодня может повторится.

Может кто то сталкивался - в какую сторону копать?
Ответы
3. Антон Стеклов (asved.ru) 33 11.01.17 06:29 Сейчас в теме
Потребление памяти MSSQL смотрите в отчете memory consumption, диспетчер задач может отображать не всю используемую память. Также посмотрите использование памяти ОС утилитой rammap от sysinternals.

Ознакомьтесь и посмотрите, что происходит у Вас: https://habrahabr.ru/post/216309/
В начале рабочего дня сделайте DBCC SQLPERF (N'sys.dm_os_wait_stats', CLEAR); потом в течение дня контролируйте ожидания запросом из статьи.

И наконец, определитесь, есть у вас проблемы или нет. Описанные вами события еще не говорят о проблемах.

(1)
Программа 1CV8C.exe версии 8.3.7.2008 прекратила взаимодействие с Windows и была закрыта

Если это происходит регулярно, формируем дамп, ТЖ и шлем на v8@1c.ru. Как это сделать - написано на ИТС.
2. Виталий Попов (Сурикат) 162 10.01.17 14:39 Сейчас в теме
Посмотрите очереди к ресурсам на MS SQL.
А динамические обновления были до падения? Сколько всего rphost? Как загружены ядра?
rphost в обязательном порядке нужно настраивать на перезапуск, ибо утечки-утечки Т_Т. Ждем 8.3.10

У нас было так:
1. 1 rphost, 64Гб оперативы по полам (32 - SQL, 32 - 1С)
Подвисания, медленная работа, при этом SQL загружен не был. Кушал все, что давали и чувствовал себя хорошо. Общая загруженность процессора порядка 5%, одно ядро почти под 90% всегда.
2. 8 rphost, 64Гб оперативы по полам (32 - SQL, 32 - 1С)
Производительность выравнялась, НО этого хватало на 4 часа без перезапусков rphost'ов (где-то 2-3 Гб на 1 rphost). Слишком частый перезапуск вызывал подвисания клиентов. При этом свободной памяти было порядка 2 Гб...
3. 8 rphost, 128Гб оперативы (72 - SQL, 56 - 1С)
Увеличили размер одного rphost до 5,5 Гб, уменьшилась частота перезапуска, работа стабилизировалась.

Ну и разумеется на динамическое обновление табу.
4. Besica ™ (besica) 11.01.17 13:36 Сейчас в теме
(2)
Посмотрите очереди к ресурсам на MS SQL.
А динамические обновления были до падения? Сколько всего rphost? Как загружены ядра?
rphost в обязательном порядке нужно настраивать на перезапуск, ибо утечки-утечки Т_Т. Ждем 8.3.10


Перед падением - очереди были пустые, постепенно отваливались пользователи - все висело.
Дин обновлений не было, 8 рпхостов - нам хватает обычно, проблемы начинаются только когда какой то регламент изменения данных прошлых периодов запускается - к вечеру начинает подтормаживать.
РПхосты за 1ГБ обычно не вылазят - перезапуск их настроен.

К моменту падения процессоры были загружены на 1-2%.
Оператива не была съедена - только половина из всего объема была использована.

И наконец, определитесь, есть у вас проблемы или нет. Описанные вами события еще не говорят о проблемах.


Проблема не повторилась(ттт) - и все опять как обычно))) И только в понедельник сервер упорно не хотел работать - трижды перезагружали.
Ошибок нет, ничего криминального не нашли. Видимо он не рад был первому рабочему дню.

Оставьте свое сообщение