Привет всем. И снова приходится обращаться за советом к знатокам. Ситуация следующая: имеется сервер, на нем ОС Windows Server 2012, Microsoft SQL Server 2014, Сервер 1С  платформой 8.3.25.1560. Раньше крутилась та же самая платформа, только 32 бит. После апгрейда до 64 стал прям сильно расти rphost. Растет даже ночью, когда активных сеансов остается только 3 и те активны относительно. Засек время. Ориентировочно после перезапуска сервера 1с, проходит 16 часов и rphost уже 52 Гб, после чего происходит  автоматический перезапуск рабочего процесса, как я понял, по причине занятия 80% ОЗУ (на сервере установлено 64 Гб). Все настройки сервера по дефолту, тем более, что ПРОФ не дает так уж сильно поиграться настройками кластера. Что интересно, когда стояла та же самая платформа, только 32 бит, в пике нагрузки создавалось максимум 6 рабочих процессов, суммарно занимающих около 20 Гб. И всё худо-бедно работало. Разве что, иногда, нечасто у некоторых пользователей рандомно отваливались сеансы с сообщением о нехватке памяти. Почему и решили проапгрейдить до 64 бит. Сейчас же рабочий процесс 1, но растет непомерно. Подскажите, как можно выловить причину такого роста? На что обратить внимание? Перечитал много чего, но помощь живого человека с опытом бесценна. Если говорить о "плохом коде", то почему на 32 битах он так сильно не проявлялся, а сейчас вдруг вылез? Почему на 32 бит при закрытии сеансов количество rphost уменьшалось и ночью (при двух-трех относительно активных сеансах) вообще доходило до 1, размером около 3 гб, а сейчас на 64 битах один процесс ночью (при тех же двух-трех сеансах) продолжает, пусть и медленнее, но расти. Подумал про обновление платформы, но прочитал и не увидел в ошибках этой версии хоть что-то про память. Да и опять же 32 бит той же версии работала. Люди добрые, сломал голову всю, читал и здесь темы. Возможно что-то пропустил. ))) Подскажите, ткните носом, как можно выявить причину?

отключите полнотекстовый поиск

Что тут думать. Ищи циклические ссылки
https://its.1c.ru/db/metod8dev/content/5859/hdoc

Кстати, 64 Гб для сервера — это очень мало. Добейте до 256 Гб

(1) Это в порядке эксперимента? Отключить и посмотреть, что будет или реально поможет решить?

(2) Ух. А сюда я и не добрался. Видимо, потому, что я не программист, а админ.  ))

(4) Вероятность очень высокая

(3) Я бы с радостью нарастил память, только финансирование могут не выделить с тем, что раньше ведь работало до апгрейда и хватало памяти.

(2) Но как быть с тем, что на 32 битах эти циклические ссылки (если они есть) не занимали так сильно память, а теперь занимают?

(8) Ну потому как объем памяти процесса x32 ограничен. У тебя доходило до предела и сервер убивал стары и создавал новый процесс.
Соответственно у тебя постоянная ротация происходила.
В x64 нет такого ограничения.
Ну укажи в настройках кластера интервал перезапуска поменьше и будет как раньше.
Ну или в параметрах рабочего сервера укажи критический объем памяти процессов. Сервер 1с будет там сам ими управлять при перерасходе. Хотя я хз это возможно в обычной 1С или это только для лицензий уровня корп

(9) По моему, это КОРП. Да и перезапускать не хотелось бы постоянно. Если найти причину, то и решить уж как-то можно будет. Но я постоянно смотрю на 32 бит. При закрытии большинства активных сеансов и rphost меньше становился. Ночью оставался 1 процесс на 3 гб. А сейчас ночью он всё равно растёт.

(0) последняя нормальная платформа без лавинообразного роста - 22я.
потом - начался и продолжается адЪ.....
естественно, во всех десятках баз выключены все полнотекстовики....не в этом вовсе дело....

(11) Ну не знаю. У нас альфа-авто 6 (8.3.25.1394) с доработками на 100 пользователей.
В свойствах кластера: "Интервал перезапуска" = 10000.
В свойствах ИБ: "Резервирование рабочих процессов" = Истина
Полнотекстовый поиск включен.
Проблем не наблюдаем. Редко за 5 Гб рабочий процесс переходит.

Я готов и 10 Гб рабочий процесс потерпеть. Это, ведь, несерьёзно - ставили 64 бит с расчетом на улучшение стабильности и хоть какой-то производительности, а по факту получили еще большую головную боль.

(13) 10gb....это несерьезно...мелочь....

И еще сейчас обратил внимание. Рядом в стойке стоит другой сервер на Линукс и там PostgreSQL и так же самая 64-битная платформа 1с. Правда, конфигурации другие, но рабочий процесс более-менее стабильно 4 гб. Вот мистика какая-то. Хоть бы какую-нибудь методику, как выявить источник бед. Я так понимаю, что кроме ТЖ других способов нет?

(15) Отключите на ночь регламентные и фоновые задания.

(16) Хорошо, попробую. Заодно и полнотекстовый поиск отключу. Спасибо за советы.