Мы рассмотрим распространенную проблему, когда процесс rphost сервера 1С:Предприятие значительно увеличивает загрузку центрального процессора (ЦП) при выполнении регламентных заданий, особенно при работе с СУБД PostgreSQL. Выясним основные причины такого поведения и предложим комплексные решения для оптимизации производительности.
Наблюдение высокой загрузки ЦП процессом rphost во время выполнения регламентных заданий – это не редкость. Давайте проанализируем, почему это происходит, и чем ситуация на PostgreSQL может отличаться от MS SQL.
Загрузка конфигурации и контекста в память:
Одной из ключевых причин повышенной нагрузки на процессор является необходимость процесса rphost каждый раз загружать конфигурацию информационной базы и соответствующий контекст в оперативную память для выполнения регламентного задания. Если информационная база была неактивна, и после завершения работы пользователей rphost выгрузил данные из ОЗУ, то каждый новый запуск регламентного задания требует повторной загрузки этих данных. Этот процесс интенсивного чтения с диска и инициализации в памяти вызывает пиковые нагрузки на ЦП.
Мы можем сравнить это поведение с работой веб-серверов. Например, веб-сервер Apache по умолчанию может выгружать часть своего контекста из памяти после простоя, и первый запрос к нему будет выполняться дольше, пока все не будет загружено обратно. В то время как IIS чаще держит все необходимое в памяти, что обеспечивает более быстрый отклик, но требует больше оперативной памяти постоянно. В контексте 1С сервер MS SQL часто более агрессивно кеширует данные в оперативной памяти, что может снижать потребность rphost в повторной загрузке данных с диска, тем самым уменьшая нагрузку на ЦП при старте заданий. PostgreSQL, в свою очередь, имеет свои механизмы кеширования, но взаимодействие с rphost может приводить к упомянутым пикам.
Одновременный старт множества заданий:
Если в кластере 1С настроено множество регламентных заданий, которые запускаются одновременно или с минимальным интервалом, это практически гарантированно приведет к скачкообразному росту загрузки ЦП. Каждый такой запуск требует инициализации отдельного сеанса 1С и загрузки данных, как мы уже обсуждали. Даже если сами алгоритмы заданий относительно "легковесные", их массовый одновременный старт создает лавинообразную нагрузку.
"Корявый код" в 1С:
Как показал опыт автора темы, одной из фундаментальных причин проблемы может быть неоптимизированный или "корявый" код внутри самой конфигурации 1С. Это могут быть запросы, которые выполняются неэффективно, чрезмерные циклы обработки данных, отсутствие использования индексов в запросах, или операции, которые приводят к блокировкам или долгому ожиданию СУБД. Даже если регламентное задание кажется простым, за ним могут скрываться сложные или неоптимальные алгоритмы обработки данных, разработанные без учета производительности.
Неактуальные индексы и статистика в СУБД:
Сложные запросы, используемые в регламентных операциях, могут значительно дольше выполняться, если статистика по таблицам в СУБД неактуальна или индексы фрагментированы. Оптимизатор запросов СУБД строит план выполнения, основываясь на имеющейся статистике. Если она устарела, план может быть неэффективным, что приводит к большему количеству операций ввода-вывода и, как следствие, повышенному потреблению ресурсов ЦП.
Для решения проблемы высокой загрузки ЦП процессом rphost мы предложим комплексный подход, затрагивающий как настройки платформы 1С, так и конфигурацию СУБД PostgreSQL, а также непосредственно код конфигурации.
Первым и часто наиболее эффективным шагом является правильная настройка расписания выполнения регламентных заданий.
Разнесение по времени:
Одним из наиболее действенных способов снижения пиковой нагрузки является распределение выполнения ресурсоемких регламентных операций по времени. Вместо того чтобы запускать все задания одновременно, мы можем настроить их последовательный запуск. Например, как показал опыт из обсуждения, запуск по одной информационной базе в минуту, с повтором через час, может кардинально изменить ситуацию. Это позволяет серверу 1С последовательно обрабатывать задания, избегая 100% загрузки ЦП. Мы можем настроить расписание каждого регламентного задания индивидуально через интерфейс 1С:Предприятия. Для этого перейдем в раздел Администрирование - Обслуживание - Регламентные и фоновые задания и для каждого задания зададим уникальное расписание.
В некоторых случаях может потребоваться программное управление расписанием, например:
// Пример программного изменения расписания для задания "ОбновлениеИндексаППД"
РегламентноеЗадание = РегламентныеЗадания.НайтиПоИмени("ОбновлениеИндексаППД");
Если РегламентноеЗадание <> Неопределено Тогда
Расписание = РегламентноеЗадание.ПолучитьРасписание();
Расписание.Заполнить(ИспользованиеРасписанияРегламентногоЗадания.КаждыеЧасы, 0); // Каждые 0 часов (т.е. один раз)
Расписание.Секунды = 0;
Расписание.Минуты = 5; // Запуск в 5 минут каждого часа
Расписание.Часы = 10; // В 10:05
// Усложним, если нужно разнести на разные минуты для разных баз
// Например, для базы с префиксом "БП01" в 10:05, для "БП02" в 10:06 и так далее
РегламентноеЗадание.УстановитьРасписание(Расписание);
КонецЕсли;
Конечно, такая тонкая настройка чаще делается через графический интерфейс, где мы можем выбрать дни недели, время и интервалы повторения. Главное — избегать одновременного старта множества ресурсоемких операций.
Перенос на нерабочее время:
Максимально перенесем ресурсоемкие операции, такие как формирование сложных отчетов, перепроведение документов за большой период, обновление индексов, на ночное время или часы минимальной активности пользователей. Это позволяет освободить ресурсы сервера в пиковые рабочие часы и минимизировать влияние на производительность системы для активных пользователей.
Отключение ненужных заданий:
Регулярно проводим аудит регламентных заданий. Отключаем те, которые не используются или не имеют критического значения для работы системы. Особенно это актуально для файловых баз, где любое фоновое задание может значительно замедлять работу пользователей. В клиент-серверном варианте это тоже важно, так как каждое активное задание потребляет ресурсы сервера.
Зависимость от функциональных опций:
Мы можем настраивать регламентные задания так, чтобы они не запускались, если связанная с ними функциональность отключена в настройках конфигурации. Это предотвратит запуск лишних сеансов 1С и избыточное потребление ресурсов сервера.
Правильная конфигурация сервера 1С:Предприятия играет важную роль в общей производительности системы.
Актуальная версия платформы 1С:
Регулярно обновляем платформу 1С:Предприятие до последних стабильных версий. Разработчики постоянно выпускают оптимизации, направленные на снижение системных требований, улучшение производительности и исправление ошибок, которые могут влиять на загрузку ЦП. Например, в последних версиях платформы (8.3.25 и выше) были внесены существенные оптимизации для снижения потребления памяти полнотекстовым поиском и ускорения первоначального подключения клиента к информационной базе. Наряду с платформой необходимо поддерживать в актуальном состоянии и сами информационные базы, для чего можно настроить автоматическое архивирование, обновление и тестирование баз 1С по расписанию в тихом режиме.
Отключение автоматического закрытия баз:
Некоторые пользователи отмечают, что отключение автоматического закрытия баз в настройках рабочего сервера 1С:Предприятия может помочь сохранить контекст информационной базы в памяти rphost. Это уменьшает количество повторных загрузок при каждом запуске регламентного задания и, как следствие, снижает пиковую нагрузку на ЦП. Мы можем найти эту настройку в консоли администрирования кластера серверов 1С.
Выделение отдельного рабочего сервера для фоновых заданий:
Если фоновые задания постоянно генерируют значительную нагрузку (например, более 20% от общего потребления ЦП), мы можем настроить кластер 1С таким образом, чтобы фоновые задания выполнялись на отдельном рабочем сервере. Это позволяет распределить нагрузку между несколькими процессорами или ядрами и обеспечить стабильную работу пользователей на основном сервере. Такой подход особенно актуален для больших и нагруженных систем, хотя требует дополнительных лицензий и ресурсов.
Анализ технологического журнала 1С:
Для глубокой диагностики и выявления конкретных причин высокой загрузки процессора мы настоятельно рекомендуем использовать технологический журнал 1С. Он позволяет фиксировать все события на сервере 1С, включая длительность выполнения серверных вызовов, запросов к СУБД, ошибки и многое другое. Анализируя данные журнала, мы можем определить, какие именно серверные вызовы, процедуры или объекты конфигурации вызывают проблемы с производительностью. Инструменты для анализа ТЖ (например, конвертеры в XML и просмотрщики) помогут нам наглядно увидеть "узкие места".
Правильная настройка СУБД PostgreSQL критически важна для производительности 1С, особенно в условиях высокой нагрузки от регламентных заданий.
Использование сборки Postgres Pro для 1С:
Мы настоятельно рекомендуем использовать специализированные сборки Postgres Pro, оптимизированные для работы с 1С:Предприятием. Эти сборки включают патчи и улучшения, разработанные специально для сценариев использования 1С, такие как:
При создании кластера Postgres Pro для 1С мы рекомендуем использовать команду initdb с параметрами --tune=1c --locale=ru_RU.UTF-8 для автоматической настройки основных параметров подсистемы.
Обновление статистики и перестройка индексов:
Мы должны регулярно выполнять операции ANALYZE для обновления статистики по таблицам. Актуальная статистика позволяет оптимизатору запросов PostgreSQL строить наиболее эффективные планы выполнения. Для интенсивно изменяемых таблиц также может потребоваться периодическая перестройка индексов. Это можно делать с помощью утилиты pg_repack, которая позволяет перестраивать индексы без блокировки таблиц. Частота этих операций зависит от интенсивности изменений данных в базе.
Ключевые параметры памяти в postgresql.conf:
Мы проанализируем и настроим следующие параметры в файле postgresql.conf:
<strong>shared_buffers</strong>: Этот параметр определяет количество оперативной памяти, выделенной PostgreSQL для общего кеша страниц данных. Рекомендуется устанавливать его в диапазоне от 25% до 50% от общего объема ОЗУ сервера. Слишком низкое значение приведет к частым обращениям к диску, слишком высокое – может мешать кешированию ОС и другим процессам.<strong>work_mem</strong>: Определяет максимальный объем памяти, который может быть использован для внутренних операций запросов, таких как сортировка и хеширование, для каждого отдельного соединения. Если значение слишком низкое, PostgreSQL будет использовать временные файлы на диске, что значительно замедлит работу. Если слишком высокое, это может привести к нехватке памяти при большом количестве одновременных запросов. Начнем с 4-8MB и по необходимости увеличим, контролируя общее потребление.<strong>temp_buffers</strong>: Максимальный объем памяти для временных таблиц в каждом сеансе. 1С интенсивно использует временные таблицы, поэтому правильная настройка этого параметра важна. Установим его в разумных пределах, например, 32-64MB, если видим, что временные таблицы активно сбрасываются на диск.<strong>effective_cache_size</strong>: Этот параметр не выделяет память, а дает оптимизатору запросов оценку размера кеша операционной системы, который доступен для использования PostgreSQL. Он помогает оптимизатору решить, стоит ли использовать индексный скан или последовательное сканирование. Рекомендуется устанавливать его в 50-75% от общего объема ОЗУ сервера.<strong>default_statistics_target</strong>: Увеличение этого параметра (например, до 500-1000) может улучшить качество построения плана запроса за счет сбора более подробной статистики, хотя и увеличит время выполнения ANALYZE.max_connections:
Мы устанавливаем количество одновременных соединений (max_connections) исходя из реального количества активных пользователей, к которому добавляем запас для регламентных и фоновых заданий, а также административных подключений. Избыточное значение может привести к излишнему потреблению памяти, недостаточное — к отказам в обслуживании.
Настройки BIOS сервера:
Для максимальной производительности СУБД рекомендуется отключать функцию HyperThreading (или SMT) и все функции энергосбережения в BIOS сервера. HyperThreading может создавать непредсказуемые задержки и снижать производительность при высокой нагрузке, а энергосбережение может замедлять реакцию процессора.
Запрет своппинга разделяемой памяти:
Мы должны запретить операционной системе выгружать в своп разделяемую память, используемую PostgreSQL. Это критически важно для производительности. В Linux это достигается настройкой параметра vm.swappiness=1 (или 0) и использованием mlockall для процесса PostgreSQL, чтобы он всегда держал свои сегменты памяти в ОЗУ.
Как мы уже выяснили из исходной дискуссии, "корявый код" в 1С может быть основной причиной проблемы. Мы сосредоточимся на его анализе и оптимизации.
Использование управляемых блокировок:
Мы обеспечим правильное использование управляемых блокировок в прикладном решении, особенно в типовых конфигурациях. Неправильное или избыточное использование блокировок, а также их отсутствие там, где они необходимы, может привести к замедлению работы и конфликтам доступа к данным, что в свою очередь увеличивает нагрузку на ЦП.
Анализ и переработка "корявого кода":
Самый трудоемкий, но и наиболее эффективный шаг — это выявление и переработка неоптимизированного кода. Мы будем искать:
EXPLAIN ANALYZE) для оценки их производительности.ОБНОВИТЬ, ВСТАВИТЬ, УДАЛИТЬ в рамках одной транзакции, что гораздо эффективнее.Для исправления такого кода могут потребоваться глубокие знания платформы 1С и принципов работы СУБД.
Высокая загрузка процессора при выполнении регламентных заданий в 1С с PostgreSQL — это комплексная проблема, которая требует системного подхода. Мы рассмотрели различные аспекты: от настройки расписания заданий и конфигурации сервера 1С до тонкой настройки СУБД PostgreSQL и оптимизации кода конфигурации. Применяя эти рекомендации, мы сможем значительно снизить нагрузку на ЦП и улучшить общую производительность системы 1С:Предприятия.