Как устранить медленную работу 1С в связке с PostgreSQL?

← На главную

Медленная работа 1С в связке с PostgreSQL — это распространенная проблема, которая часто проявляется не сразу, а по мере накопления данных или интенсивной работы пользователей. В рассматриваемой ситуации мы видим классический симптом: производительность системы восстанавливается после реиндексации и реструктуризации, но через 3–5 дней документы снова начинают проводиться крайне медленно (до 2 минут). Это прямо указывает на неоптимальные настройки СУБД и операционной системы. Разберем пошагово, как диагностировать и решить эту проблему.

Анализ текущего состояния и поиск узких мест

Прежде чем приступать к изменению настроек, нам необходимо точно выяснить, что именно тормозит. Рассмотрим ситуацию, когда база данных имеет объем 30 Гб, а сервер оснащен 32 Гб ОЗУ. Проанализируем сообщения форума и дополним их практическими шагами:

Замер времени в отладчике. Это первое, с чего стоит начать программисту. Мы должны запустить замер времени при проведении «тяжелого» документа. Если задержка происходит на конкретных строках кода (например, при выполнении запроса или записи в регистры), мы поймем, в какую сторону копать — в сторону оптимизации запроса или в сторону настроек СУБД.
Получение плана запроса. Если замер времени показывает, что «зависание» происходит на одном конкретном запросе, необходимо получить его план выполнения (Query Plan). Это поможет выяснить, использует ли СУБД индексы или выполняет полное сканирование таблицы (Full Scan).
Анализ логов PostgreSQL. Проанализируем логи в периоды наибольшего замедления. Особое внимание уделим параметру log_min_duration_statement. Если установить его в значение 2000ms, сервер будет записывать в лог все запросы, которые выполнялись дольше 2 секунд.

Тонкая настройка параметров памяти PostgreSQL

Одной из ключевых причин замедления является неправильное распределение оперативной памяти. Рассмотрим настройки postgresql.conf для сервера с 32 Гб ОЗУ.

Параметр shared_buffers. В исходном сообщении было указано значение 2048 Мб. Для базы в 30 Гб это крайне мало. Выясним причину: shared_buffers определяет объем памяти, который PostgreSQL использует для кэширования данных. Если данные не помещаются в этот кэш, СУБД постоянно обращается к диску. Для Windows-версии PostgreSQL оптимально установить 8 Гб (около 25% от всей памяти). Большие значения в Windows могут работать нестабильно из-за особенностей кэширования операционной системы.

Параметр work_mem. Этот параметр определяет объем памяти для операций сортировки и группировки внутри одного запроса. 1С часто генерирует сложные запросы. Если work_mem слишком мал, временные результаты сбрасываются на диск, что резко замедляет работу. Рекомендуем установить 64–128 Мб.

Параметр maintenance_work_mem. Он влияет на скорость создания индексов и работу вакуума. Установим его в значение 1–2 Гб, чтобы регламентные операции проходили быстрее.

Параметр effective_cache_size. Это «подсказка» планировщику запросов о том, сколько памяти доступно в кэше ОС. Установим его на уровне 20–24 Гб (около 75% всей ОЗУ).

Борьба с «распуханием» таблиц и настройка Autovacuum

Если реиндексация помогает на 3–5 дней, значит, база страдает от накопления «мертвых» строк (bloat). В PostgreSQL при изменении или удалении записи старая версия строки остается на диске и помечается как неиспользуемая. Очисткой этих строк занимается autovacuum. Рассмотрим, как заставить его работать агрессивнее.

Разберем настройки в postgresql.conf:


autovacuum = on
autovacuum_max_workers = 5
autovacuum_vacuum_scale_factor = 0.01
autovacuum_analyze_scale_factor = 0.005

По умолчанию autovacuum_vacuum_scale_factor равен 0.2. Это значит, что очистка начнется только после изменения 20% данных в таблице. Для 1С это недопустимо много. Установив 0.01 (1%), мы добьемся того, что очистка будет запускаться гораздо чаще, не позволяя таблицам «раздуваться».

Регламентное обслуживание базы данных

Помимо автоматических процессов, необходимо настроить ночные регламенты. Разберем основные операции:

REINDEX. В отличие от MS SQL, PostgreSQL сильнее подвержен деградации индексов. Если вы замечаете тормоза через неделю работы, настройте еженедельное выполнение REINDEX DATABASE в часы минимальной нагрузки.
ANALYZE. Обновление статистики необходимо для того, чтобы планировщик выбирал оптимальные пути выполнения запросов.
VACUUM FULL. Эту операцию стоит применять с осторожностью, так как она полностью блокирует таблицы. Рассмотрим ее использование только в случаях критического разрастания файлов базы данных, когда обычный вакуум не справляется.

Оптимизация на уровне операционной системы Windows

Поскольку сервер работает под управлением Windows Server 2016, проанализируем специфические настройки ОС:

План электропитания. Это критически важный момент для серверов 1С. Проверим, чтобы в настройках Windows был установлен режим «Высокая производительность» (High Performance). В режиме «Сбалансированный» частота процессора может динамически снижаться, что вызывает микрозадержки, к которым 1С крайне чувствительна.
Исключения антивируса. Убедимся, что из сканирования исключены:
- Исполняемые файлы postgres.exe и ragent.exe.
- Папки с данными базы данных PostgreSQL.
- Временные папки (Temp) пользователей, под которыми работают службы 1С и PostgreSQL.
Использование Shared Memory. Если сервер приложений 1С и PostgreSQL находятся на одном физическом сервере, настроим их взаимодействие через общую память, а не через TCP/IP. Это снизит накладные расходы на сетевой стек.