Добрый день, коллеги! У меня есть обмен по правилам обмена между базой КА 1.1 и базой БП 3. Релиз БП Бухгалтерия предприятия, редакция 3.0 (3.0.99.19) и платформа 1С:Предприятие 8.3 (8.3.18.1334)

Загрузка идет регламентным заданием, само задание сформировано из внешней обработки. Так вот до недавнего времени не было проблем с обменом на данной почве, а именно "Аварийно завершился рабочий процесс фонового задания" при загрузке файлом данных в БП. Сейчас если загружаю реализации товаров за 1,5 месяца, несколько тысяч документов - рег. задание валится, приходится загружать по две недели вручную, естественно автообмен не работает. Есть похожая проблема https://forum.mista.ru/topic.php?id=850074 , но там типовой обмен, а у меня свой написан. \

Замечено, что после перезапуска службы 1С ошибка в меньше степени проявляется, при накоплении периода работы платформы без перезапуска ошибка чаще возникает.ю
---
Платформа какая? Если 32 бита, возможно превышение максимального объема памяти процессом rphost, лечится только переходом на платформу x64 или разбивкой обмена на мелкие порции.
---
конфликт с другими заданиями, почаще период обмена сделайте, если задача разовая заблокируйте все фоновые на время
---
В 1С Бухгалтерии никто не работает, заданий не выполняется параллельно, если разбить на более мелкие порции выгрузку, проходит без проблем.
---
(5) В 1С Бухгалтерии никто не работает, заданий не выполняется параллельно, если разбить на более мелкие порции выгрузку, проходит без проблем.
  Фоновые выключите именно фоновые
---
Аварийно завершился рабочий процесс фонового задания - это все, что вы можете получить из всяких там, понимаешь, логов?
--
память, диск, количество юзеров (толкотня вокруг таблиц) ?
---
Память свободна, диск свободен, юзеров ноль, толкотни не наблюдается вокруг таблиц.
---
Платформа какая? Если 32 бита, возможно превышение максимального объема памяти процессом rphost, лечится только переходом на платформу x64 или разбивкой обмена на мелкие порции.
---
Платформа 32, я пробовал на 64х выполнять обмен, проблема наблюдается также, разбивка на мелкие порции требует ручного вмешательства в обмен, каждый день делать это руками - такое не подойдет.
---
обновлять оболочки. пол года с этой бедой воевали, на последних оболочках вроде стало получше. раньше была скрытая настройку что если рп хост видит что занято больше 75% памяти то вырубает процесс......
1С:Предприятие 8.3 (8.3.18.1483) вот на этой пока не наблюдали
---
Интересная тема, я тоже что-то такое подозревал, так как до опредленного времени проблем не было, появились с переходом с одной платформы на другую при кратном увеличении переносимых данных (документов).
---
а где эта скрытая настройка, не подскажите?
---
или расход памяти на процесс или количество памяти на процесс. где то в свойствах кластера или менеджера
---
Если клиент-серверный вариант отключите teredo, ipv6 и возможно еще лишние виртуальные сетевые адаптеры. Скорее всего СУБД разрывает соединение когда видит обращения с этих адаптеров.
---
Попробуем, спасибо.
---
Попробуйте увеличить количество рабочих процессов на сервере 1С, это даст возможность серверу "разбивать" нагрузку на части. Что-то подобное по этой ссылке обсуждалось https://forum.infostart.ru/forum9/topic121332/
---
Попробуйте увеличить количество рабочих процессов на сервере 1С, Это справедливо сейчас для конфигураций КОРП или нет?
---
количество рабочих процессов на сервере 1С

Для этого нужно иметь лицензию КОРП
---
Если у вас серверный вариант размещения, тогда разумеется есть сервер 1С, на нем могут быть любые конфигурации, в том числе и корп и настройки можно сделать. Если вариант размещения базы "Файловый" тогда не подходит.
---
Исходных данных маловато.
Клиент тонкий или толстый?
База на сервере 1С или файловая?
Apache случаем не замешан в обмене?
---
Если речь идет о серверном варианте работы без использования лицензий КОРП, то есть настройки кластера могут быть только стандартными, максимальная память, выделенная одному процессу RPHOST, составляет 8% оперативной памяти сервера 1С. Кто не верит, не устраивайте холивар здесь, пишите в личку, обсудим. Поэтому при выполнении обменов, формировании масштабных отчетов и других ресурсоемких операциях память рабочего процесса может быть превышена на значительно большее время, чем задано в настройках кластера, а их поменять без лицензии КОРП нельзя. Поэтому вариантов обычно два - или выделять серверу 1С значительно больше памяти, чем ему на самом деле требуется, или разбивать масштабные операции на порции поменьше.
---
RPHOST, составляет 8% оперативной памяти
Добрый день! А если сервер на котором несколько баз и стоит настройка 1 ИБ на процесс, то 8% от физ памяти сервера на один RPHOST или суммарный объем всех RPHOST сервера должен быть не больше 8% от физ памяти сервера?

Те я наблюдаем что фоновые задания завершаются с ошибкой
"Аварийно завершился рабочий процесс фонового задания" при этом размер RPHOST который завершается всего 600мб.
---
Итак, смотрим информацию в этой статье:

https://its.1c.ru/db/v8319doc#bookmark:cs:TI000000158
Кстати, статья изменилась, мне кажется, раньше там было меньше букв.

Привожу здесь интересующие нас выдержки:

Безопасный расход памяти за один вызов

Примечание. Доступно только для лицензии КОРП. Подробнее о видах лицензий см. здесь.

Объем памяти в байтах, использование которого в процессе вызова сервера считается безопасным.

Может принимать значение от -1 до 9 223 372 036 854 775 807:

● -1 ‑ любой вызов сервера считается опасным, если за время вызова сервера объем памяти, занятый процессами кластера (рабочих процессов и менеджеров кластера), достигает используемого значения свойства Временно допустимый объем памяти процессов;

● 0 ‑ значение объема определяется автоматически, как 10% от используемого значения параметра Временно допустимый объем памяти процессов.

Временно допустимый объем памяти процессов

Определяет размер временно допустимого объема оперативной памяти, занятой рабочими процессами и менеджерами кластера (процессами кластера) на настраиваемом рабочем сервере, в байтах. Если объем памяти, потребляемой процессами кластера, превышает значение параметра, то система считает, что у данного рабочего сервера снижается производительность и на него больше не следует назначать новые соединения с информационными базами.

Данное значение используется для контроля над объемом памяти, которое используют рабочие процессы в целом и отдельный серверный вызов в частности:

● Контроль над памятью рабочих процессов.

Если параметр Временно допустимый объем памяти процессов оставался превышенным на время большее, чем указано в параметре Интервал превышения временно допустимого объема памяти процессов (параметр должен иметь значение большее 0), то начинается перезапуск рабочих процессов данного рабочего сервера. Перезапуск выполняется, начиная с рабочего процесса, потребляющее максимальное количество памяти в порядке уменьшения объема потребляемой оперативной памяти. При этом процесс перезапуска будет прекращен тогда, когда сумма потребляемой памяти оставшимися процессами кластера станет меньше или равна параметру Временно допустимый объем памяти процессов.

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

● Контроль над памятью серверного вызова.

Каждый рабочий процесс кластера определяет объем памяти, занимаемой процессами кластера на этом рабочем сервере (назовем это значение ПамятьПроцессов). ПамятьПроцессов обновляется один раз в две секунды.

При начале вызова сервера фиксируется текущее значение ПамятьПроцессов на момент начала вызова (назовем это значение ПамятьПроцессовТекущая) и вычисляется разность значения Временно допустимый объем памяти процессов и значения ПамятьПроцессовТекущая (назовем это значение ПределПамятиЗаВызов). Если значение ПределПамятиЗаВызов получилось меньше значения Безопасный расход памяти за один вызов, то значением ПределПамятиЗаВызов становится значение Безопасный расход памяти за один вызов.

В процессе выполнения вызова вычисляется объем памяти, израсходованной при выполнении этого вызова (назовем это значение ПамятьЗаВызов).

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

● Текст исключения;

● Контекст исключения.

Параметр может принимать значение от -1 до 9 223 372 036 854 775 807:

● -1 ‑ временно допустимый объем памяти, доступный процессам кластера на данном рабочем сервере, не ограничен;

● 0 ‑ в качестве временно допустимого объема памяти процессов кластера на данном рабочем сервере используется значение по умолчанию:

● Для контроля над памятью рабочих процессов ‑ 70% объема оперативной памяти сервера.

● Для контроля над памятью серверного вызова ‑ 80% объема оперативной памяти сервера.

Значение по умолчанию равно 0.

Раньше я делал вывод, что максимальный расход памяти одного серверного вызова составит 10% от 80%, то есть 8% всей оперативной памяти сервера.

Сейчас можно прикинуть подробнее. Допустим, у нас на сервере 64Гб памяти, тогда Временно допустимый объем памяти процессов составит примерно 51Гб и Безопасный расход памяти за один вызов примерно 5Гб. Допустим, сервер 1С недавно перезапустили, на нем существует 1 рабочий процесс, который потребляет 1Гб. Тогда ПамятьПроцессов у нас будет 1, ПамятьПроцессовТекущая тоже 1, отнимаем от 51Гб 1, получаем ПределПамятиЗаВызов, равный 50Гб. 50Гб больше, чем 5Гб, поэтому ПределПамятиЗаВызов остается 50Гб.

Если же на сервере 16Гб, и на каждую ИБ выделен 1 процесс, что, кстати, 1С не рекомендует делать в другой статье (https://its.1c.ru/db/metod8dev/content/5908/hdoc), так как "значительное число процессов rphost приводит к неэффективному использованию памяти процессами кластера", и все эти процессы потребляют уже сейчас 12Гб, тогда:
- Временно допустимый объем памяти процессов = 12,2Гб
- Безопасный расход памяти за один вызов = 1,2Гб
- ПамятьПроцессовТекущая = 12Гб
- 12,2 - 12 = 0.2, это меньше, чем 1.2, тогда ПределПамятиЗаВызов = 1.2Гб

Так что при прочтении текущей версии статьи выходит, что при наличии большого количества свободной оперативной памяти каждый серверный вызов может потребить количество памяти, значительно превышающее 8% ее объема, а когда свободной памяти остается мало, тогда этот параметр (Безопасный расход памяти за один вызов) начинает работать.

Вы можете провести свои собственные расчеты, взяв за основу реальные данные Вашего сервера, текущей и средней нагрузки на него.

Если Вы можете использовать настройку 1 ИБ на процесс, значит, используете лицензию КОРП, в этом случае можно поставить все эти параметры в -1 (ничего не ограничивать) и повторить эксперимент. Если процессы перестанут падать, дело в памяти, если продолжат, нужно искать другую причину.
---
Добрый день, коллеги! Решение найдено. Правильный ответ я отметил. Спасибо за участие.
---
А что из отмеченного помогло? Использование х64 или разбивка на мелкие части?
---
Помогло использование x64
---
Возможно процесс длиться слишком долго, система считает его зависшим и завершает(в случае установки параметра "Завершать зависшие процессы")
---
где вы видели , что бы долго выполняющийся процесс считался системой зависшим ?
 Там не все так просто .. зависшие процессы это набравшие аварийные ошибки , которые по совокупности сбоев или параметров вышли за некие лимиты. Это ошибки и памяти, и обращенй и т.д... .Но никак не по времени
---
(25) если на сервере установлен параметр "Проблемные процессы завершать через:" пардон писал по памяти дома.. а в целом все и так было ясно.. так что читайте мануал и будет вам счастье..
---
вот я про мануал и писал Вам ) Что понятие - проблемных процессов - это не так просто...
---
В свойствах локального кластера сервера есть секция "Перезапускать рабочие процессы" , там есть параметр в секундах "Интервал перезапуска". Если там стоит не 0, то рабочие процессы будут перезапускаться с заданным интервалом. Для пользователей это будет не заметно. Вместе с установленным флагом "Завершать зависшие процессы", длительные процессы типа обмена данными не умеют переезжать с одного процесса на другой. В этом случае обмен упадет а в журнале вы получите ошибку выше. Время от которого идет отсчет для перезапуска, можно увидеть в самом рабочем процессе.