Обеспечение высокой производительности клиент-серверной версии 1С:Предприятие при работе на бесплатной СУБД PostgreSQL — задача нетривиальная, особенно если сервер работает под управлением операционной системы Windows Server. Часто администраторы и разработчики сталкиваются с ситуацией, когда мощное серверное оборудование загружено лишь частично, но пользователи продолжают жаловаться на многосекундные задержки при выполнении критически важных операций (например, при формировании сетки занятости в медицинских информационных системах или построении сложных отчетов). В этой статье мы подробно и пошагово разберем, как локализовать «узкие места», правильно настроить СУБД, исправить критические ошибки администрирования операционной системы и оптимизировать саму конфигурацию 1С.
Прежде чем приступать к тонкой настройке СУБД или оптимизации программного кода 1С, необходимо убедиться в том, что операционная система Windows Server настроена корректно и не ограничивает производительность оборудования.
Восстановление файла подкачки (Pagefile)
Одной из наиболее распространенных ошибок является полное отключение файла подкачки на серверах с большим объемом оперативной памяти (например, 32 ГБ и более). Администраторы полагают, что если физической памяти достаточно, то отключение виртуальной памяти повысит скорость работы системы. Однако архитектура Windows Server устроена принципиально иным образом. Операционная система требует наличия файла подкачки для резервирования виртуального адресного пространства (Commit Charge). Без него процессы СУБД postgres.exe или рабочие процессы сервера 1С rphosts могут сталкиваться с отказами в выделении памяти или вести себя нестабильно, даже когда физическая ОЗУ занята лишь наполовину.
Для исправления этой ситуации выполним следующие действия:
Размер кластера NTFS для дисков с базами данных
При форматировании дисков под базы данных PostgreSQL по умолчанию часто создается файловая система NTFS с размером кластера 4 КБ. Для СУБД это крайне неэффективно. Стандартом производительности для дисковых подсистем под управлением баз данных является размер кластера 64 КБ. Несоответствие физического размера страниц СУБД и кластера операционной системы приводит к возникновению избыточных операций ввода-вывода (так называемый Split I/O), что существенно снижает скорость работы SSD-накопителей на операциях случайного чтения и записи.
Настройка планов электропитания
Убедимся, что в настройках электропитания Windows Server выставлена схема «Высокая производительность» (High Performance), а в настройках BIOS/UEFI сервера отключены все технологии энергосбережения процессора (C-States, Intel SpeedStep и др.). Это гарантирует, что тактовая частота ядер процессора всегда будет находиться на максимальном уровне, предотвращая микрозадержки при переключении частот в моменты резкого роста нагрузки от 1С.
Стандартные настройки PostgreSQL по умолчанию ориентированы на крайне слабые машины, чтобы СУБД могла гарантированно запуститься на любом компьютере. Для сервера с 32 ГБ оперативной памяти и быстрыми серверными SSD-накопителями базовые параметры требуют кардинального изменения. Откроем конфигурационный файл postgresql.conf и внесем следующие изменения:
Управление кэшем и планировщиком запросов:
random_page_cost = 1.1 (по умолчанию 4.0). Это ключевой параметр для серверов с SSD-дисками. Значение 4.0 сообщает планировщику СУБД, что случайное чтение с диска в 4 раза медленнее последовательного (что справедливо для старых HDD). Из-за этого СУБД часто отказывается от использования индексов и делает полный скан таблиц (Seq Scan). Установка значения в диапазоне 1.1–1.5 заставит планировщик активно использовать индексы.effective_cache_size = 16GB или 20GB (по умолчанию 4GB). Этот параметр не выделяет память физически, а сообщает планировщику, какой объем оперативной памяти ОС доступен для кэширования файлов БД. Чем выше этот показатель, тем более сложные и эффективные планы запросов с использованием индексов будет строить планировщик.shared_buffers = 1GB или 1.5GB (по умолчанию 128MB). На операционной системе Windows не рекомендуется устанавливать этот параметр выше 2 ГБ из-за особенностей работы с памятью и риска утечек в адресном пространстве процесса. Оптимально держать его в районе 1.5 ГБ, так как Windows активно использует собственное кэширование файлов.Оптимизация операций записи и временных таблиц:
synchronous_commit = off (по умолчанию on). Отключение синхронной фиксации транзакций дает колоссальный прирост производительности на операциях записи. При наличии источника бесперебойного питания (ИБП) на сервере это полностью безопасно. В худшем случае (при аварийном выключении питания сервера) могут быть потеряны транзакции за последние 1–2 секунды, но сама структура базы данных не будет повреждена.work_mem = 64MB или 128MB (по умолчанию 4MB). Задает объем памяти, используемый для сортировки и сложных операций внутри одного запроса. Если запросу не хватает этого объема, он сбрасывает временные данные на диск, что резко снижает скорость. Для 60 пользователей значение в 128 МБ обеспечит быструю обработку сложных аналитических запросов в ОЗУ.Настройка механизма очистки (Autovacuum):
Платформа 1С генерирует огромное количество временных таблиц и часто обновляет данные. Если механизм автоматической очистки (Autovacuum) не успевает обрабатывать изменяемые таблицы, статистика СУБД устаревает, и запросы начинают критически тормозить. Зададим более агрессивные параметры очистки:
autovacuum_max_workers = 4
autovacuum_vacuum_scale_factor = 0.05
autovacuum_analyze_scale_factor = 0.02
Это заставит СУБД гораздо быстрее реагировать на изменение данных в таблицах и своевременно обновлять статистику планировщика.
Если после настройки операционной системы и СУБД точечные операции (например, открытие сетки занятости сотрудников) продолжают выполняться медленно, проблема может крыться в неоптимальном коде конфигурации или отсутствии необходимых индексов в СУБД. Чтобы точно локализовать проблему, настроим Технологический Журнал 1С.
Создадим или отредактируем файл конфигурации технологического журнала logcfg.xml (он должен располагаться в каталоге установки платформы 1С, например, C:\Program Files\1cv8\conf\). Настроим его на сбор событий работы с СУБД PostgreSQL и вызовов сервера, длительность которых превышает 5 секунд (5000 миллисекунд):
<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-journal">
<log location="C:\v8\logs" history="24">
<event filter="">
<eq property="Name" value="DBPOSTGRS"/>
<gt property="Duration" value="5000000"/>
</event>
<event filter="">
<eq property="Name" value="CALL"/>
<gt property="Duration" value="5000000"/>
</event>
<property name="all"/>
</log>
</config>
После активации технологического журнала выполним на стороне клиента проблемную операцию (например, сформируем сетку занятости). Откроем сформированные лог-файлы в каталоге C:\v8\logs и найдем строки с событием DBPOSTGRS. Проанализируем SQL-запрос. Если мы видим регулярные операции последовательного сканирования таблиц (Seq Scan) на больших объемах данных, это явный признак того, что в конфигурации 1С для используемых реквизитов или измерений регистров не установлено свойство «Индексировать».
Сетка занятости сотрудников в медицинских конфигурациях — это сложнейший интерактивный инструмент, который на лету выполняет запросы к множеству регистров (графики работы, занятость кабинетов, смены, записи пациентов). Чтобы ускорить ее работу, применим следующие практические рекомендации:
Индексировать или входить в состав комплексных индексов.Если все вышеперечисленные методы оптимизации PostgreSQL не привели к желаемому результату, рекомендуется провести сравнительный тест производительности на альтернативной СУБД. Поскольку объем баз данных невелик (основная база 3.5 ГБ, остальные по 1 ГБ), мы можем развернуть тестовую «песочницу»:
Подобный эксперимент позволит точно определить источник проблемы. Если на MS SQL Server операция выполняется мгновенно, значит, узкое место кроется в неэффективной работе планировщика старой версии PostgreSQL 10.5 под ОС Windows. В таком случае оптимальным решением станет либо приобретение лицензии MS SQL Server, либо переход на современную сборку PostgreSQL (версии 15 или 16), оптимизированную для работы с 1С, либо перенос сервера баз данных PostgreSQL под управление операционной системы Linux, где эта СУБД демонстрирует гораздо более высокую производительность «из коробки».