Здравствуйте. Имеется сервер 1С на Windows Server. На нем одна база данных на MSSQL.
SQL сервер отдельно.
После перезагрузки через некоторое время процессы rphost занимают около 10 GB оперативной памяти.
Затем в течении недели процессы rphos начинают занимать около 25 GB оперативной памяти.
И в какой-то момент происходит освобождение оперативной памяти, и она становится снова в районе 10 GB под процессы rphost
В общем по истории видно, что циклически это все происходит. Рост - Освобождение - Рост - Особождение.
При этом нагрузка на сервер одинаковая примерно.
Вопрос. Можно ли как-то ограничить предел, до которой идет рост памяти под процессы rphost ?
И вообще, почему память так сильно увеличивается, c 10 аж до 25 GB ? Это особенность работы 1C сервера ?
p.s.
Что посоветуете, чтобы в принципе уменьшить расход оперативки, может быть есть какие-то утилиты, как отследить на что она реально расходуется 1C сервером... ?
SQL сервер отдельно.
После перезагрузки через некоторое время процессы rphost занимают около 10 GB оперативной памяти.
Затем в течении недели процессы rphos начинают занимать около 25 GB оперативной памяти.
И в какой-то момент происходит освобождение оперативной памяти, и она становится снова в районе 10 GB под процессы rphost
В общем по истории видно, что циклически это все происходит. Рост - Освобождение - Рост - Особождение.
При этом нагрузка на сервер одинаковая примерно.
Вопрос. Можно ли как-то ограничить предел, до которой идет рост памяти под процессы rphost ?
И вообще, почему память так сильно увеличивается, c 10 аж до 25 GB ? Это особенность работы 1C сервера ?
p.s.
Что посоветуете, чтобы в принципе уменьшить расход оперативки, может быть есть какие-то утилиты, как отследить на что она реально расходуется 1C сервером... ?
По теме из базы знаний
Найденные решения
(6)Почитайте тут:
Там же есть ссылка на мануалы по настройке этого всего.
Работает оно стабильно, судя по тому, что вы пишите. Суть, если есть свободная оперативная память, которую можно забить кэшем, временными таблицами, результатами запросов, планами запросов и так далее, то почему бы это не сделать? Иначе нужно каждый раз бегать к скулю и запрашивать данные, заново интерпретировать запросы, строить кэш, анализировать RLS, мне кажется, что если данные будут в оперативной памяти, то будет их взять оттуда быстрее, нежели получать их от скуля.
Это не особенность 1С это особенность всех программ, держать интерпретацию процедур в оперативной памяти, нежели запрашивать их с жёсткого диска для вычисления процессором, куда быстрее. Дай гуглу хрому доступ к оперативке, он сожрёт её всю.
То, что вы описываете как периодичность похоже на время жизни процесса и на ограничение по памяти, когда процесс, который переступает порог расхода по памяти просто пересоздаётся.
Там же есть ссылка на мануалы по настройке этого всего.
Работает оно стабильно, судя по тому, что вы пишите. Суть, если есть свободная оперативная память, которую можно забить кэшем, временными таблицами, результатами запросов, планами запросов и так далее, то почему бы это не сделать? Иначе нужно каждый раз бегать к скулю и запрашивать данные, заново интерпретировать запросы, строить кэш, анализировать RLS, мне кажется, что если данные будут в оперативной памяти, то будет их взять оттуда быстрее, нежели получать их от скуля.
Это не особенность 1С это особенность всех программ, держать интерпретацию процедур в оперативной памяти, нежели запрашивать их с жёсткого диска для вычисления процессором, куда быстрее. Дай гуглу хрому доступ к оперативке, он сожрёт её всю.
То, что вы описываете как периодичность похоже на время жизни процесса и на ограничение по памяти, когда процесс, который переступает порог расхода по памяти просто пересоздаётся.
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(6)Почитайте тут:
Там же есть ссылка на мануалы по настройке этого всего.
Работает оно стабильно, судя по тому, что вы пишите. Суть, если есть свободная оперативная память, которую можно забить кэшем, временными таблицами, результатами запросов, планами запросов и так далее, то почему бы это не сделать? Иначе нужно каждый раз бегать к скулю и запрашивать данные, заново интерпретировать запросы, строить кэш, анализировать RLS, мне кажется, что если данные будут в оперативной памяти, то будет их взять оттуда быстрее, нежели получать их от скуля.
Это не особенность 1С это особенность всех программ, держать интерпретацию процедур в оперативной памяти, нежели запрашивать их с жёсткого диска для вычисления процессором, куда быстрее. Дай гуглу хрому доступ к оперативке, он сожрёт её всю.
То, что вы описываете как периодичность похоже на время жизни процесса и на ограничение по памяти, когда процесс, который переступает порог расхода по памяти просто пересоздаётся.
Там же есть ссылка на мануалы по настройке этого всего.
Работает оно стабильно, судя по тому, что вы пишите. Суть, если есть свободная оперативная память, которую можно забить кэшем, временными таблицами, результатами запросов, планами запросов и так далее, то почему бы это не сделать? Иначе нужно каждый раз бегать к скулю и запрашивать данные, заново интерпретировать запросы, строить кэш, анализировать RLS, мне кажется, что если данные будут в оперативной памяти, то будет их взять оттуда быстрее, нежели получать их от скуля.
Это не особенность 1С это особенность всех программ, держать интерпретацию процедур в оперативной памяти, нежели запрашивать их с жёсткого диска для вычисления процессором, куда быстрее. Дай гуглу хрому доступ к оперативке, он сожрёт её всю.
То, что вы описываете как периодичность похоже на время жизни процесса и на ограничение по памяти, когда процесс, который переступает порог расхода по памяти просто пересоздаётся.
(9) В подавляющем большинстве случаев те тормоза, который человек замечает - это тормоза из-за загруженности дисковой подсистемы.
Если речь про тормоза самой 1С, то в вашем случае, когда сервер sql - это физически другая машина, то тут ещё потенциально дело именно в сетке и в тех задержках, которая она порождает. Я работал со схемой, когда сервер sql был отдельно от сервера 1С и они общались через общую сетку, это порождало лютые задержки в работе 1С, минимизировали сперва просто установив отдельные сетевые платы, подключив сервера на прямую метровым патч кордом. Стала работать заметно лучше, но всё равно не идеально. Идеально оно стало, когда мы докупили железок на сервер 1С и развернули скуль уже на нём.
Если речь про тормоза самой 1С, то в вашем случае, когда сервер sql - это физически другая машина, то тут ещё потенциально дело именно в сетке и в тех задержках, которая она порождает. Я работал со схемой, когда сервер sql был отдельно от сервера 1С и они общались через общую сетку, это порождало лютые задержки в работе 1С, минимизировали сперва просто установив отдельные сетевые платы, подключив сервера на прямую метровым патч кордом. Стала работать заметно лучше, но всё равно не идеально. Идеально оно стало, когда мы докупили железок на сервер 1С и развернули скуль уже на нём.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот