MS SQL server стал совсем "экономичным"
Процесс сервера 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 сервер "свободен", и сейчас понятно что процедура падения сервера сегодня может повторится.
Может кто то сталкивался - в какую сторону копать?
Обычно он был вполне таки прожорливым и съедал много.
База порядка 100 гб. - почти 24/7 - но максимальная нагрузка в рабочие дни.
В первый рабочий день сервер начал долго думать - сначала искали какие то тяжелые запросы - но по данным SQL он не был "загружен" работой - а точнее практически простаивал.
rphostы кушали по 1,5 ГБ оперативы и пытались кушать дальше.
В момент выпадания сервера была только ошибка в 1с "Программа 1CV8C.exe версии 8.3.7.2008 прекратила взаимодействие с Windows и была закрыта."
В принципе все работает - и отчеты формируются и даже большие (хотя возможно и медленнее чем обычно - 1С замеров пока не делали) - НО растут только rphost - sql сервер "свободен", и сейчас понятно что процедура падения сервера сегодня может повторится.
Может кто то сталкивался - в какую сторону копать?
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Потребление памяти MSSQL смотрите в отчете memory consumption, диспетчер задач может отображать не всю используемую память. Также посмотрите использование памяти ОС утилитой rammap от sysinternals.
Ознакомьтесь и посмотрите, что происходит у Вас:
В начале рабочего дня сделайте DBCC SQLPERF (N'sys.dm_os_wait_stats', CLEAR); потом в течение дня контролируйте ожидания запросом из статьи.
И наконец, определитесь, есть у вас проблемы или нет. Описанные вами события еще не говорят о проблемах.
(1)
Если это происходит регулярно, формируем дамп, ТЖ и шлем на v8@1c.ru. Как это сделать - написано на ИТС.
Ознакомьтесь и посмотрите, что происходит у Вас:
В начале рабочего дня сделайте DBCC SQLPERF (N'sys.dm_os_wait_stats', CLEAR); потом в течение дня контролируйте ожидания запросом из статьи.
И наконец, определитесь, есть у вас проблемы или нет. Описанные вами события еще не говорят о проблемах.
(1)
Программа 1CV8C.exe версии 8.3.7.2008 прекратила взаимодействие с Windows и была закрыта
Если это происходит регулярно, формируем дамп, ТЖ и шлем на v8@1c.ru. Как это сделать - написано на ИТС.
Посмотрите очереди к ресурсам на 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 Гб, уменьшилась частота перезапуска, работа стабилизировалась.
Ну и разумеется на динамическое обновление табу.
А динамические обновления были до падения? Сколько всего 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 Гб, уменьшилась частота перезапуска, работа стабилизировалась.
Ну и разумеется на динамическое обновление табу.
(2)
Перед падением - очереди были пустые, постепенно отваливались пользователи - все висело.
Дин обновлений не было, 8 рпхостов - нам хватает обычно, проблемы начинаются только когда какой то регламент изменения данных прошлых периодов запускается - к вечеру начинает подтормаживать.
РПхосты за 1ГБ обычно не вылазят - перезапуск их настроен.
К моменту падения процессоры были загружены на 1-2%.
Оператива не была съедена - только половина из всего объема была использована.
Проблема не повторилась(ттт) - и все опять как обычно))) И только в понедельник сервер упорно не хотел работать - трижды перезагружали.
Ошибок нет, ничего криминального не нашли. Видимо он не рад был первому рабочему дню.
Посмотрите очереди к ресурсам на MS SQL.
А динамические обновления были до падения? Сколько всего rphost? Как загружены ядра?
rphost в обязательном порядке нужно настраивать на перезапуск, ибо утечки-утечки Т_Т. Ждем 8.3.10
А динамические обновления были до падения? Сколько всего rphost? Как загружены ядра?
rphost в обязательном порядке нужно настраивать на перезапуск, ибо утечки-утечки Т_Т. Ждем 8.3.10
Перед падением - очереди были пустые, постепенно отваливались пользователи - все висело.
Дин обновлений не было, 8 рпхостов - нам хватает обычно, проблемы начинаются только когда какой то регламент изменения данных прошлых периодов запускается - к вечеру начинает подтормаживать.
РПхосты за 1ГБ обычно не вылазят - перезапуск их настроен.
К моменту падения процессоры были загружены на 1-2%.
Оператива не была съедена - только половина из всего объема была использована.
И наконец, определитесь, есть у вас проблемы или нет. Описанные вами события еще не говорят о проблемах.
Проблема не повторилась(ттт) - и все опять как обычно))) И только в понедельник сервер упорно не хотел работать - трижды перезагружали.
Ошибок нет, ничего криминального не нашли. Видимо он не рад был первому рабочему дню.
Внимание! Тема сдана в архив
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот