Платформа 8.3.5.1383. SQL 2008. Пользователей системы 5-8 человек. Памяти 8гб.

В течении дня боле-менее нормально работает. С утра почти 100% памяти загружено sqlserver.exe и тремя rghost.exe. В соединениях висят незакрытые фоновые задания.

Подключится никто не может т.к. сервер уже не справляется. 5-8 человек это в принципе и для файловой базы не так чтобы совсем много.

Куда смотреть? Где копать?

админу в глазки поглаживая паяльник

А что админ должен сделать?

(2) минимум ограничить размер доступной памяти скуля

(0) "В соединениях висят незакрытые фоновые задания" - от нас требуется телепатически выяснить, что это за задания, почему они висят и кто убил Кеннеди?

SQL надо ограничить по памяти, он прожорлив

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

среднее значение настроить мониторинг,что у вас вопросов таких не было.

(4) Да фиг знает. Но задачи и по бух 3.0, и по бух 2.0  и по зуп 2.5 думается там они разные.

(5) Я своими глазами видел нажравшегося скуля. Неограниченного. Он сожрал 186 гиг памяти из 256 гиг доступной и был спокоен, пожирая совсем по чуть-чуть.

(9) Да вроде скл не больше всех. Один rghost берет больше sql, а три rghost  в два раза больше sql.

(8) сколько баз и какого размера на сервере?

(9) Ну это зависит от размера базы. У меня сейчас занято 74 из 128 и база 60 ГБ.

(11)  > Ну это зависит от размера базы.

Основная база в sql 8гигов

(11) Имеет смысл обрезать?

(13) ага, прямо по шею

а в журнале регистрации что писалось когда сервант загружен был?

(15)
Судя по времени:
Регламентное задание. Обновление индекса полнотекстового поиска

(0) Посмотреть в монитор активности SQL-сервера? В джобы? В фоновые задания?

(17) > Посмотреть в монитор активности SQL-сервера? В джобы?

Я таких сложных слов не знаю. Если можно по пунктам куда жать.

(16) ну поздравляю. Проверяйте - там есть возможность ограничить обновление количеством элементов. Возможно у вас не установлено такое ограничение

(19) Сколько ставить?

мой склероз подсказывает что-то в районе 10 000, но я не уверен

(9) объелся видимо. У нас тока 196 гиг, ограничили до 140 его

(18) на диске ИТС есть такая обработка по управлению регламентными заданиями, поищщи в универсальных

https://bugboard.v8.1c.ru/error/000003805.html
"Объем виртуального адресного пространства, занимаемого рабочим процессом сервера Предприятия, непрерывно растет. Особенно быстрый рост наблюдается, если в кластере зарегистрированы информационные базы, с которыми пользователи не работают постоянно, но в которых определены и включены регламентные задания."

(24) это лечится настройкой перезапуска рабочих процессов в кластере. Стандартная рекомендация 1с - не менее 1 раза в 24 часа

(24) Т.е. отключаем регламентные задания в раздличных копиях/тестовых?

(26) в тестовых само собой их нафиг, без вариантов

(28) Ну да.

а нечего что как он пишет в (0) что база файловая и причем там скуль, или про что к чему?

28 к (26)

Вроде, там rphost упоминался...

(25) Настройка http://i067.radikal.ru/1501/48/1bcc4181b734.png - насколько нормальная?

(13) Лучше всего памяти добавить, если возможно.

(29) > а нечего что как он пишет в (0) что база файловая и причем там скуль, или про что к чему?

Я говорю что с 5-8 пользователями и файловый режим справляется.

(32) Время перезапуска поставь 86400

(0) не у вас одного так. У меня такая же ситуация (платформа 8.3.5.1383) - правда памяти 64 гб, и пользователей ~30. С утра прихожу, пользователей в базе нет, а rphost отожрал примерно 98% оперативки и в своп уже начинает кидать данные.
По-моему по этой ошибке уже создан багрепорт - https://bugboard.v8.1c.ru/error/000003805.html

ну ограничить память SQL'ю же

8.3.5.1383 - шибко глючная, сеансы не закрывает, на фоновых память жрет по самое не балуй.

(32)
Поменял настройки с http://i067.radikal.ru/1501/48/1bcc4181b734.png

На

http://s017.radikal.ru/i410/1501/ed/3796ad89ca9e.png

Вроде заработало нормально.

фоновые задания

https://pbs.twimg.com/media/B3SqOe8CMAAbb_V.png:large

https://pbs.twimg.com/media/B3SqOe8CMAAbb_V.png