Вопрос обновления СУБД PostgreSQL (или ее сборки Postgres Pro) всегда вызывает дискуссии среди администраторов и специалистов 1С. С одной стороны, новая версия — это всегда новые возможности и потенциальные оптимизации движка. С другой стороны — принцип «работает — не трогай» в мире 1С имеет под собой веские основания, связанные с совместимостью платформы и спецификой работы планировщика запросов. В данном материале мы подробно разберем ситуацию, когда на сервере Linux установлена связка 1С:Предприятие 8.3.23 и Postgres Pro Standard 15.1.1, и стоит задача понять: даст ли обновление до версий 15.5.x или 16.x прирост скорости, и если нет — то как этого прироста добиться.
Первым делом проанализируем обновление в рамках одной мажорной версии (Minor Release). Часто бытует мнение, что минорные обновления несут только исправления редких ошибок и не влияют на производительность. Однако в контексте PostgreSQL 15 это не совсем так.
Давайте разберем, почему обновление с 15.1.1 до актуальной версии ветки 15 (например, 15.5.1 и выше) строго рекомендуется, даже если вы не ожидаете взрывного роста скорости:
plantuner или online_analyze могут устранить случаи, когда оптимизатор строит неэффективный план запроса для динамических списков 1С.Вывод по минорному обновлению: Ожидать прироста скорости работы 1С на 20-30% не стоит. Скорость останется примерно на том же уровне. Однако обновляться нужно обязательно ради сохранности данных и стабильности работы индексов.
Теперь рассмотрим переход на PostgreSQL 16. Казалось бы, новая редакция должна работать быстрее. Но в связке с платформой 1С версии 8.3.23 здесь кроются серьезные подводные камни.
Официальная поддержка PostgreSQL 16 в платформе 1С:Предприятие заявлена начиная с версии 8.3.27. Это означает следующее:
libpq.scram-sha-256 по умолчанию) могут потребовать ручной перенастройки pg_hba.conf и параметров соединения, что часто приводит к ошибкам подключения рабочих процессов rphost.Давайте посмотрим на новшества PG 16 техническим взглядом. Улучшения касаются параллелизма (Parallel Query), работы с JSON через SIMD-инструкции и мониторинга ввода-вывода (pg_stat_io). Для глубокого анализа событий системы также применяют перенос логов технологического журнала в ClickHouse.
Специфика архитектуры 1С такова, что:
Seq Scan (последовательное чтение) вместо Index Scan, что приведет к замедлению.Вывод по мажорному обновлению: Переходить на PostgreSQL 16 на платформе 8.3.23 не рекомендуется. Риски несовместимости высоки, а выигрыш в скорости отсутствует.
Если простое обновление СУБД не дает прироста скорости, необходимо обратить внимание на настройки операционной системы и конфигурации PostgreSQL. Часто именно настройки "по умолчанию" в Linux являются бутылочным горлышком для высоконагруженных систем 1С.
Рассмотрим ключевые точки оптимизации, которые реально влияют на отзывчивость системы.
По умолчанию Linux использует страницы памяти размером 4 КБ. Для современных серверов с десятками и сотнями гигабайт ОЗУ это приводит к огромным накладным расходам процессора на трансляцию адресов памяти (TLB misses).
В Linux существует механизм Transparent Huge Pages (THP), который включен по умолчанию, но для баз данных он работает плохо, вызывая микрофризы (замирания) при попытке системы "на лету" объединить страницы.
Рекомендация:
# В файле /sys/kernel/mm/transparent_hugepage/enabled
# должно быть выбрано [never] или [madvise]
echo never > /sys/kernel/mm/transparent_hugepage/enabled
shared_buffers в PostgreSQL.
В конфиге PostgreSQL параметр huge_pages должен быть установлен в try или on.
Это снижает нагрузку на CPU и делает работу с памятью более предсказуемой.
Современные процессоры агрессивно экономят энергию, снижая частоту ядер в простое. Linux по умолчанию часто использует режим ondemand или powersave. Для сервера 1С это критично: когда приходит запрос, процессору нужно время, чтобы поднять частоту. Пользователь в этот момент видит "лаг".
Решение: Перевести процессор в режим максимальной производительности.
# Проверка текущего режима
cpupower frequency-info
# Установка режима performance
cpupower frequency-set -g performance
Это исключает задержки на переключение частот при резких всплесках нагрузки.
Если сервер физический и имеет несколько дисков, крайне полезно разнести саму базу данных и журнал предзаписи (WAL) на разные физические носители.
Журнал предзаписи (pg_wal) требует последовательной записи с высокой скоростью. Файлы данных требуют рандомного доступа (чтение/запись). Разделение этих потоков ввода-вывода существенно снижает конкуренцию за диск.
В 1С это делается через создание табличных пространств (tablespaces) и перемещение туда баз данных, либо через симлинки на уровне файловой системы для каталога pg_wal.
Стандартный конфиг postgresql.conf не рассчитан на профиль нагрузки 1С. Рассмотрим параметры, которые нужно корректировать.
1С активно использует временные таблицы и часто обновляет регистры итогов (РегистрНакопления.Итоги). Это создает много "мертвых" кортежей (dead tuples). Если процесс автовакуума не успевает их вычищать, таблицы раздуваются (bloat), и чтение из них замедляется.
Рекомендуется сделать настройки более агрессивными, чем по умолчанию:
autovacuum_vacuum_scale_factor = 0.01 # Запускать вакуум при изменении 1% данных, а не 20%
autovacuum_analyze_scale_factor = 0.005
autovacuum_naptime = 20s # Проверять чаще
autovacuum_vacuum_cost_limit = 1000 # Дать вакууму больше ресурсов
Эти настройки помогут держать базу в компактном состоянии.
Планировщик PostgreSQL иногда ошибается, считая, что сканирование всей таблицы дешевле, чем использование индекса (особенно на SSD дисках). Параметр random_page_cost по умолчанию равен 4.0 (для HDD). Для SSD его следует уменьшить до 1.1–1.2.
random_page_cost = 1.1
effective_cache_size = [50-70% от RAM] # Подсказка планировщику о доступном кэше ФС
Подводя итог нашему анализу, сформулируем план действий:
random_page_cost под SSD диски.Такой подход обеспечит стабильную работу системы и позволит выжать максимум из имеющегося оборудования без риска нарушения совместимости.