1с уменьшить объем памяти

Обновлено: 06.01.2025

Бывают случаи, когда процесс rphost отъедает много ОЗУ (Иногда даже всю свободную).

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

В результате, даже соседним процессам «Сервера 1С» ее может не хватать, как и всем остальным процессам на данном сервере (особенно если на борту уже есть MS SQL, сервер терминалов, веб сервер и прочие).

К слову, подобные вещи уже давно происходят и с MS SQL, чьи аппетиты не редко приходится усмирять администраторам.

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

Разберем различные способы, которые позволяют решить проблему «утечек» памяти rphost – а.

В 1С признают официально, что утечки памяти есть (на техническом уровне), и проблема не решена. Обещают решить с выходом версии 8.3.20. Также есть надежда, что с выходом 8.3.20 решат и в целом проблему повышено потребления памяти процессами 1С.

На «Сервер 1С» к сожалению, не все так просто как с MS SQL, здесь есть и ограничения версии «ПРОФ», и новые версии платформы. К примеру с 8.3.15 убрали возможность настройки «Допустимый объем памяти», что дополнительно давало нам возможность самим влиять на потребление памяти одного rphost-а. Некоторые настройки перенесли в «Параметры рабочего сервера».

Правда, обещают, что с версии 8.3.20 вернут обратно некоторые настройки регулирования потребления ОЗУ и для версии «ПРОФ», так как на сегодня, это возможно сделать, только используя «КОРП».

В 1С также временами не могут определиться, что оставить в «ПРОФ» а что перенести в «КОРП»:

Что также здорово «запутывает» пользователя.

Но и это еще не все )

Многие эксперты утверждают, что настроек «Сервера 1С» по умолчанию вполне достаточно, и что «Сервер 1С» не надо перезапускать.

Это утверждение только отчасти является верным!

Настройки «по умолчанию» имеют право быть, если действительно нет утечек памяти и других критических проблем, «Сервер 1С» не вылетает с ошибками и тд.

А утечки случаются и при небольших нагрузках (на «ПРОФ») и они как минимум могут требовать перезапуска рабочих процессов (rphost) так и более тонких настроек.

Правдой является и то, что перезапуск целого «Сервера 1С» не является «острой» необходимостью, так как корректного перезапуска rphost-а почти всегда достаточно, чтоб освободить память, и не навредить пользователям, которые в этот момент могут работать в 1С Предприятии.

Перезапуск «Сервера 1С» делаем только когда это действительно необходимо.

(К примеру, разово, в начале расследования утечки памяти).

Далее будет достаточно перезапуска rphost.

В разы же возрастает необходимость внесения правок, если у нас «КОРП»!

Есть высоконагруженные системы, где работают сотни пользователей, тогда действительно требуется чаще вносить изменения в параметры руками на «Сервере 1С», сюда и создание отказоустойчивого кластера, путем добавления «Рабочего сервера», также настройка, направленная на борьбу с утечками памяти (они встречаются и в «КОРП») а их в кластере будет еще больше.

А вот что касается части настроек с целью повысить как то производительность «Сервера 1С» (Не учитывая создания отказоустойчивого кластера серверов 1С), то вот здесь настройки как для «ПРОФ» так и «КОРП» будут малоэффективные.

Что ж, глубину проблемы мы с вами уяснили, теперь начинаем «распутывать».

Сперва разберемся, какое потребление rphost считать за нормальное.

Если говорить прямо, то сегодня на один RPHOST уже уходит больше 4ГБ ОЗУ.

В более старых конфигурациях 1С, эта цифра может быть меньше, а вот в новых (особенно ERP и подобных «тяжелых») , 10 -15 и больше ГБ, уже будет за норму.

ВАЖНО!

Напрасно надеется, что «Серверу 1С» хватит пары Гб, что остались у вас свободны, и тут никакие оптимизации не спасут!

Что в основном влияет на потребление ОЗУ процессом rphost:

Количество сеансов
Конфигурации 1С
КОД (Качество написания)
Фоновые задачи (Порожденные регламентными заданиями).
Версия платформы 1С

Первое что стоит сделать в борьбе с утечкой:

Останавливаем «Сервер 1С», и очистим кэш на «Сервере 1С»!

И затем после его запуска в «боевых» условиях мы посмотрим на потребление ОЗУ в течение короткого времени от 30 мин до

Бывает, что rphost чрезмерно потребляет ОЗУ не сразу, а на протяжении всего рабочего дня или даже нескольких дней. (Можно увидеть «утечку»).

После чего надо пройтись по сеансам!

С них я и всегда предлагаю начинать расследование, так как именно ошибки (не оптимально написанный код) чаще всего и вызывает «утечки».

Память (текущая) в сеансах.

Это объем переданных и полученных данных с момента начала клиентского соединения (в байтах).

Отсортируем по наивысшим показателям эти сеансы, после чего стоит пристально разобрать у пользователей, где на сеанс ушло больше всего ОЗУ, что они делают в этот момент в 1С, какие отчеты, документы, обработки запускают.

Затем получив список объектов, мы проводим их диагностику на уровне кода в конфигурации, конечно с привлечением программиста 1С.

Если после анализа, качество кода конфигурации 1С не вызывает у вас сомнения (разобрали что происходит в сеансах пользователей), тогда это и будет «обычное» (или близкое к этому) потребление RPHOST-ов ОЗУ у Вас.

В том случаи, если вместо «приложения» у вас «фоновая задача» кушает много ОЗУ, следует разобрать ее.

Если автор «фонового» известен, тогда поиск проблемы будет сильно упрощен, нам останется только отключить регламентные задачи, которые породили «фоновое задание», что у нас и имеет сильное потребление. (Вкладка Администрирование – Регламентные и фоновые задания).

Если вместо пользователя у вас автор «фоновой задачи» «DefUser» или трудно, поймать, кто запускает «фоновую задачу».

Тогда можно пойти другим путем и в целом на «Сервере 1С» установить «Блокировку регламентных задач» после чего перезапустить «Сервер 1С».

Конечно, совет будет вредным если рег. задания у вас в конфигурации нужны!

Далее рассмотрим случай, когда явно есть «утечка памяти», а разбор кода и отключение регламентных задач не решили проблему:

Обычно в этом случаи администраторы выполняют перезапуск «Сервера 1С», прямо скажем не очень хорошая идея, особенно когда это происходит посреди рабочего дня.

Более правильно, но только для «Аврала» ) будет установка «интервала перезапуска» в свойствах локального кластера:

Установив 86400 секунд, мы автоматизируем процесс перезапуска рабочего процесса раз в сутки (Ночью).

Сделайте настройку так, чтоб не попасть в рабочее время!

Конечно, это не решит проблему «утечки» но с симптомом позволит бороться, это на тот случай если у вас абсолютно нет времени предпринять что-то более изящное.

Если Вы хотите больше узнать о технической стороне 1С, тогда регистрируйтесь на первый бесплатный модуль курса: Администратор 1С >>>

Оптимизация использования оперативной памяти

Область применения: управляемое приложение, мобильное приложение, обычное приложение.

Методическая рекомендация (полезный совет)

1. Не следует разрабатывать решения исходя из неограниченного объема оперативной памяти. Для многопользовательских систем любое неэффективное использование памяти может катастрофически сказаться на работоспособности.

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

2. При потенциально неограниченных выборках данных из ИБ следует получать данные из базы порциями фиксированного размера.
Например, неправильно:

// Выгрузка всего справочника в таблицу значений
Номенклатура = Запрос.Выполнить().Выгрузить();
Для каждого ПозицияНоменклатуры Из Номенклатура Цикл
// Обработка элемента справочника
// .
КонецЦикла;

поскольку весь результат запроса сразу помещается в память, в таблицу значений.
Также неправильно:

РезультатЗапроса = Запрос.Выполнить();
// Обход результата запроса
ВыборкаДетальныеЗаписи = РезультатЗапроса.Выбрать();
Пока ВыборкаДетальныеЗаписи.Следующий() Цикл
// Обработка элемента выборки
// .
КонецЦикла;

поскольку и в этом случае при выполнении запроса его результат будет сначала считан в память целиком (*).

* Примечание. Если используется 32-битная версия платформы, и размер результата запроса превосходит размер имеющейся памяти, то данные будут записаны на диск, а затем считаны оттуда в процессе вызовов Выборка.Следующий().

Правильно ограничивать результат запроса искусственно:

РезультатЗапроса = Запрос.Выполнить();
ВсеОбработано = РезультатЗапроса.Пустой();
Если ВсеОбработано Тогда
Прервать;
КонецЕсли;

// Обход порции результата запроса
ВыборкаДетальныеЗаписи = РезультатЗапроса.Выбрать();
Пока ВыборкаДетальныеЗаписи.Следующий() Цикл
// Обработка элемента выборки
// .
КонецЦикла;

Выборка = Справочники.Номенклатура.Выбрать(. Отбор);
Пока Выборка.Следующий() Цикл
// Обработка элемента выборки
// .
КонецЦикла;

поскольку в этом случае платформа 1С:Предприятие выполняет получение данных из базы порциями фиксированного размера.

Кроме того, число элементов выборки автоматически ограничивает платформа 1С:Предприятие в запросах динамических списков.

3. Недопустимо работать с большими XML документами с помощью объектов встроенного языка, предназначенных для обработки файлов целиком: текстовые документы в ТекстовыйДокумент , XML в ДокументDOM и HTML в ДокументHTML , а также создавать в памяти XDTO-пакеты размером с весь XML-файл целиком.

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

Следует использовать объекты для последовательной записи и последовательного чтения: ЧтениеXML , ЧтениеТекста , ЗаписьXML , ЗаписьТекста , с помощью которых можно прочитать файл порциями и расходовать память экономно.

При использовании механизмов XDTO неправильно зачитывать в память весь XML-файл целиком ( ФабрикаXTDO.ПрочитатьXML(ЧтениеXML) ). Вместо этого следует зачитывать XML-файл последовательно, с помощью объекта ЧтениеXML , а его отдельные фрагменты (теги) десериализовывать с помощью фабрики XDTO.

4. Другая распространенная причина неэффективное использование памяти - утечки памяти. К утечкам памяти приводит создание циклических ссылок – память выделяется и не освобождается. Например, если есть объекты, внутри которых вложены другие объекты, и где-то в глубине они ссылаются на самый верхний объект. В результате образуется циклическая ссылка.
Упрощенный пример циклической ссылки:

Данные = Новый Структура;
Данные.Вставить("Ключ", Данные);

Следует разрывать (очищать) ссылки, когда объект становится не нужен.
Например, для примера выше:

Значительное потребление памяти процессами кластера на сервере приложений

У кластера серверов 1С Предприятия есть несколько настроек перезапуска процессов по превышению порога памяти. Их можно найти в параметрах кластера в консоли администрирования(рис. 1).

Рис. 1. Параметры кластера.

Подробная информация по настройкам указана на странице ITS.

Рекомендуется всегда настраивать параметры

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

"Допустимый объем памяти" стоит устанавливать из расчета, того, что в случае срабатывания условия превышения показателя будет запущен ещё один процесс rphost того же объема, как при нормальной работе кластера серверов в этой информационной системе.

Например, на рабочем сервере имеем 12 Гб ОЗУ. Допустим для конкретной информационной системы характерен размер rphost около 3 Гб. В этом случае порог превышения памяти следует рассчитывать следующим образом:

"Допустимый объем памяти" = 12 ГБ - 2 Гб (объем, занимаемый процессами системы) - 3 Гб * 1 rphost (объем всех процессов rphost) = 7 Гб. Т.е. процесс rphost в худшем сценарии может вырасти до 7 Гб.

Для случая, когда у нас при штатной работе используются два процесса rphost.

"Допустимый объем памяти" = 12 ГБ - 2 Гб (объем, занимаемый процессами системы) - 3 Гб * 2 rphost (объем всех процессов rphost) = 4 Гб. Т.е. процесс rphost в худшем сценарии может вырасти до 4 Гб.

Такая рекомендация исходит из особенностей поведения в момент перезапуска процессов кластера. Как это происходит:

процесс rphost превышает "Допустимый объем памяти" в течение "Интервал превышения допустимого объема памяти" секунд, срабатывает условие перезапуска процессов кластера.
запускается "новый" процесс rphost
"старый" процесс rphost выключается, но не завершается
соединения назначаются на "новый" процесс rphost, который сразу полноценно включается в работу
"старый" процесс будет исполнять вызовы (которые ещё существуют) максимум в течение ещё "Выключенные процессы останавливать через" секунд, но не более того.
через время "Выключенные процессы останавливать через" "старый" процесс rphost завершается.
новый процесс полноценно работает

Т.е. в течение периода, указанного в "Выключенные процессы останавливать через" будет одновременно работать как минимум два процесса rphost: "старый" и "новый".

Не следует указывать "Допустимый объем памяти" меньше нормального рабочего объема памяти процесса rphost для вашей системы, т.к. противном случае у вас постоянно будут перезапускаться процессы кластера серверов.

Интервал превышения допустимого объема памяти
Выключенные процессы останавливать через

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

Чем больше значения указанных параметров, тем менее эффективен может оказаться механизм перезапуска процессов, но зато позволит "успешно выполнить" большее число вызовов.

Несколько постов в нашей группе телеграмм послужили причиной для написания данной статьи.

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

«MS SQL скушал, забрал, использовал всю оперативку»

Действительно не редкие случаи, когда MS SQL чрезмерно употребляет ОЗУ и если не убавить его аппетиты можно и совсем остаться без свободной оперативной памяти.

Первое так сказать быстрое и «почти универсальное» решение проблемы чрезмерного употребления ОЗУ в MS SQL это указать в свойствах MS SQL (вкладка «Память») тот объем ОЗУ, который мы можем отдать на нужды «сиквела». (Не забывайте после перезапустить MS SQL)

Более подробная информация по вопросу выделения ОЗУ, есть на курсе: Администратор 1С.

На картинке выше указанно 4 Гб которые может употребить MS SQL (И обычно за «Максимальный размер памяти сервера он и не выходит»).

Таким образом, мы снимаем «острую» проблему с потреблением ОЗУ в MS SQL.

Конечно, при всем этом сразу возникает много вопросов:

1. Почему MS SQL не освобождает память ?

2. Сколько ОЗУ для моего MS SQL установить ?

3. Как определить сколько ОЗУ нормально для MS SQL ?

4. Можно-ли не наращивать объем ОЗУ для MS SQL ?

5. Чем грозит ОЗУ в MS SQL ?

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

Главный вопрос: «Почему MS SQL не освобождает память, неужели он не умеет это делать ?

Умеет!

MS SQL умеет динамически работать с ОЗУ!

Вот что пишет MS:

Когда SQL Server использует память динамически, он периодически опрашивает систему, чтобы определить объем свободной физической памяти. SQL Server использует API уведомления памяти QueryMemoryResourceNotification, чтобы определить, когда можно выделить и освободить память буферного пула.

Но почему же это не всегда происходит?

Все просто.

1С Предприятие по своей «натуре» создает много временных таблиц, которые вынуждают MS SQL брать больше ОЗУ, заполнять свой буферный пул теми данными, которые в 1С часто востребованы, чтоб обеспечить максимальною производительность.

Безусловно, это нормально поведение не только MS SQL, но и большинства других СУБД.

Только сведя к минимуму операции ввода /вывода с диска (работая с ОЗУ) можно добиться максимальной производительности, что собственно и пытается делать MS SQL.

К сожалению не только «природа» 1С Предприятия способствует чрезмерным аппетитам «сиквела», тут здорово помогают и «кривые запросы» и «ошибки» в коде, и конечно все это ведет к тому, что MS SQL употребляет ОЗУ больше чем мы рассчитывали, (часто всю что видит).

Другими словами, MS SQL не виноват в том, что 1С «дает повод» брать больше ОЗУ и не дает основания ее освобождать.

Благо в MS SQL есть инструмент позволяющий «руками» ограничить потребление ОЗУ, что собственно в самом начале статьи и продемонстрировали на скрине.

Конечно, помимо инструментов есть, и советы от Microsoft касательно MS SQL:

Рекомендуется устанавливать MS SQL единственным (кроме системы) софтом.

Так он не будет конфликтовать за ресурсы с другими программами и сможет взять ОЗУ сколько ему потребуется.

Объем ОЗУ (в идеале) должен быть равен размеру всех баз.

Другими словами если у Вас 3 базы по 10 Гб, размер ОЗУ для MS SQL в идеале 30 Гб.

Безусловно в идеале и «миллион» долларов вряд ли бы кого расстроил ) но исходим от того что имеем ), и 30% процентов от баз также будет очень хорошо! (Во многих случаях и меньше того).

Физика работы MS SQL, проста в базовом плане потребления ОЗУ, помещаем в буфер то, что часто используется, чтоб обеспечить как можно лучшую производительность.

Если «сиквел» обнаружит, что у него всего 30% ОЗУ он будет просто больше писать и читать с диска и обходится тем, что есть. Да, конечно, всему есть придел и слишком большой дефицит ОЗУ приведет сперва к падению производительности (хорошо будет заметно при формировании отчетов в 1С), а потом и к различным ошибкам, вплоть до «вылета» программы.

(Рекомендую время от времени просматривать журнал MS SQL не сыпется ли уже ошибки связанные с памятью, особенно обратить внимание на строки memory pressure).

Вот мы и подошли к еще одному Важному вопросу:

«Так сколько ОЗУ надо для счастливой» жизни «сиквелу» ) ?

В рамках данной статьи, попытаюсь дать ответ и на этот не простой вопрос, или как минимум указать верное направление)

Читайте также: