Собственно сколько раз эта тема не мусолилась, но опять с этим процессом проблемы. Работает сервер 1с х64, в настройках кластера сервера интервал перезапуска раб. процессов 21600, допустимый объем 4194303, интервал превышения допустимого объема 60. Все было хорошо почти месяц. Работало 2 раб. процесса + 2 резервных на 35 пользователей. Из 64 гигов оперативы всегда было свободно 40 гигов, 20 гб под себя резервировала SQL(там не только 1с крутится) и около 4 гб откушивали rphost. Прямо таки идиллия, но прихожу после выходных и вижу, что один из процессов стал кушать 17гб 0_0. При этом перезапуск процесса не срабатывает, процесс не очищается. Какие еще могут на это влиять настройки? Обновлений за этот месяц не было, в конфигурации сервера ни чего не менялось.
Перезапуск службы 1с сервера это конечно хорошо, но все таки, что может блокировать очистку процесса когда целый месяц все отрабатывало хорошо?

(0) не указана версия платформы

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

У меня тут на днях rphost 173 ГБ сожрал. Кто то отчетик, я думаю, очень "оптимальный" наваял. Думал сервак сдохнет. Не, выдержал. Буду искать, кто это такой прожорливый.

(0) решения кроме перезапуска платформы я не нашел хоть и сильно искал в свое время. Решил все через автоматический перезапуск сервера 1с ночью.

(1)Сорри, платформа 8.2.19.68.
(2) Т.е. как понимаю, может получиться  так, что после рестарта службы будет опять месяц все отлично, а потом опять тоже самое?
Про случайные моменты это понятно, вопрос именно про настройки кластера, толку от них если не рестартуют процесс, время задержки перевалило уже за сутки, но процесс все висит и висит, кушает оперативу и в ус не дует.
Кстати заметил еще один интересный момент, посмотрел по соединениям, к нему подключен только планировщик заданий, остальные пользователи подключены ко второму раб. процессу.

(0)

>перезапуск процесса не срабатывает, процесс не очищается

посмотри в свойствах процесса его номер и сделай
taskkill /pid <номер процесса>

(6) Благодарю за подсказку, на сколько это реально сделать во время работы пользователей? Не будет какого нибудь краха?

Вопрос про настройки кластера все равно актуален, имеет смысл на них ориентироваться или они чисто условны?

З.ы. недавно на sql перешли, вот и знакомлюсь с новыми тонкостями...

(7) будет крах конечно
(5) конечно может повторится, но скорей всего причина в (3), 90% проблем из-за кривых алгоритмов. Опять же платформа 8.2.19.68 - имхо не самая стабильная, смотри ошибки на сайте 1с

+ в технологическом журнале включить leak и mem
Но скорее всего какой-нибудь интересный отчет

(7) для того чтобы этого избежать:
заводишь второй процесс
первый, который отожрал память, делаешь неактивным
ждёшь, пока юзеры плавно переползут на второй процесс (это происходит быстро)
taskkill первый процесс
PROFIT!!!

(8) а какую, кстати, из 8.2 кошернее ставить? я тут как раз озадачился выбором

(11) ставь 7.7.27

(10)
>>это происходит быстро
если рпхост так разбух - не факт что быстро
(11) последння 18-я на мой скромный взгляд достаточно стабильна, если из 19-тых - то тоже ближе к последним, никак не 68-ю

(0)не правильно настроенный типовой отчет за минуту может съесть всю память

и считается перезапуск сервера 1с хотя бы раз в неделю это норма

У меня: 1С:Предприятие 8.2 (8.2.18.96)
Лично отловленный глюк этой платформы: при попытке обрезать журнал регистрации на определенную дату, ЖР очищается полностью.

(12) да это добро стоит уже где-то )))
нужна возможность выбора данных из внешних источников во временные таблицы

(15) у тебя не правильная платформа, у меня тоже 8.2.18.96 - обрезается журнал номрально, недавно на 15-ти базах многогиговых обрезали

(13) спс, попробую 18ю

> если рпхост так разбух - не факт что быстро

вообще действительно хз. мы так фоновые задания завершали зависшие. переползали все быстро на новый процесс, правда с памятью там проблем не было

(15) да фиг с ним, с журналом, главное чтобы сама платформа работала

(12) Я бы не ставил. Слишком новая, необкатанная. 7.7.25 понадежнее будет.

(8).1 если в кластере серверов есть резервирование - никаких проблем кроме недолгого подвисания не будет

8.2.19.68 - такого глюка не наблюдаем.. .около года назад была точно такая-же фигня... версию уже не вспомню. Как временное решение - по вечерам воскр. перезагружали сервер (благо у нас это возможно).

(10) помогло, правда долго все таки это делается. Спасибо за подсказки, будем разбираться дальше. А по поводу платформы, может не очень стабильна, но на ней меньше всего блокировок выскакивает почему то лично у нас

Заметил кстати интересную тенденцию, до того момента пока не убил процесс отожравший много оператив, остальные процессы так же не очищались. После очистки вручную одного процесса в течении получаса очистились остальные.
Кстати taskkill не требуется, перевел процесс в раздел резервных, как только все юзеры от туда уползли он убился сам.

(0)у тебя ночью кто-нить работает с 1с?

(24)Только я сам, в тестовой базе. Но она крутится в файловом режиме на другом сервере.