При переходе с файлового варианта или СУБД MS SQL Server на PostgreSQL многие администраторы и разработчики 1С сталкиваются с неприятным сюрпризом: скорость записи данных падает в несколько раз. Особенно ярко эта проблема проявляется на тяжелых транзакционных операциях, таких как проведение документов за большой период или проведение документа «Расчет себестоимости» в конфигурации «Управление производственным предприятием» (УПП 1.3). В то время как файловая база на SSD справляется с расчетом за 4 минуты, а MS SQL — за 7–17 минут, PostgreSQL может тратить на ту же операцию около часа.
В этой статье мы подробно разберем, почему возникает этот критический затык при записи, как архитектурные особенности платформы 1С влияют на производительность СУБД, и какие конкретные шаги необходимо предпринять, чтобы ускорить PostgreSQL до уровня MS SQL Server.
---
Если проанализировать замеры производительности в момент «зависания» PostgreSQL, можно заметить, что СУБД тратит огромное количество времени на запись и удаление данных в различных таблицах, при этом нагрузка на дисковую подсистему и процессор сервера может оставаться минимальной. СУБД как будто «чего-то ждет».
Основная причина такого поведения кроется в устаревшем режиме совместимости конфигурации. Многие старые конфигурации (включая типовую УПП 1.3) по умолчанию используют режим совместимости Версия 8.2.13 или Версия 8.2.16. При работе в этом режиме платформа генерирует запросы к СУБД по старым алгоритмам, которые крайне неэффективны для архитектуры PostgreSQL.
Давайте разберем по шагам, что меняется при переходе на режим совместимости Версия 8.3.8 и выше:
DROP TABLE и TRUNCATE. В PostgreSQL операции манипулирования структурой таблиц накладывают жесткие блокировки на системный каталог СУБД (таблицы метаданных pg_catalog), вызывая его сильное раздувание (bloat) и провоцируя транзакционные ожидания. Начиная с режима совместимости 8.3.8, механизмы работы с временными таблицами на стороне платформы были кардинально переработаны, что снизило нагрузку на системный каталог PostgreSQL в разы.БлокироватьДляИзменения), что минимизирует вероятность взаимных блокировок и ускоряет запись многострочных документов в СУБД.Результат на практике: простой перевод копии базы УПП 1.3 в режим совместимости Версия 8.3.8 позволяет сократить время проведения документа «Перемещение товаров» с 30 до 12 секунд, а расчет себестоимости ускоряется с 54 минут до 22 минут!
---
Перевод рабочей базы на новый режим совместимости — это ответственный процесс, требующий предварительного тестирования. Напрямую изменить свойство в конфигураторе типовой УПП не всегда возможно без исправления ошибок компиляции, так как новые версии платформы предъявляют более жесткие требования к коду и метаданным.
Рассмотрим алгоритм перехода:
Версия 8.3.8 (или выше, например, Не использовать, если позволяет код).При переходе со старых режимов совместимости вы гарантированно столкнетесь со следующими проблемами, которые необходимо будет устранить вручную:
Картинка1 и картинка1). Новые требования платформы этого не разрешают. Вам придется переименовать конфликтующие объекты.---
Помимо настроек самой платформы 1С, крайне важно правильно подготовить конфигурационный файл PostgreSQL postgresql.conf. По умолчанию СУБД поставляется с очень консервативными настройками, рассчитанными на слабые компьютеры. Наша задача — заставить СУБД использовать ресурсы сервера (в нашем примере — сервер с 24 ГБ ОЗУ и SSD) по максимуму.
Ниже представлены проверенные параметры конфигурации для обеспечения высокой скорости записи:
1. Настройки памяти и временных буферов
Для того чтобы СУБД реже обращалась к диску при обработке временных таблиц 1С, увеличим объемы выделяемой памяти:
# Выделяем память под кэш данных (рекомендуется около 25% от общего объема ОЗУ)
shared_buffers = 6GB
# Объем памяти для кэширования временных таблиц в рамках одной сессии
temp_buffers = 128MB
# Объем памяти для выполнения сложных сортировок и группировок в одном запросе
work_mem = 128MB
# Память для сервисных операций (индексация, очистка VACUUM)
maintenance_work_mem = 1GB
2. Оптимизация записи и транзакционного лога (WAL)
Самое «узкое» место PostgreSQL при записи — это сброс транзакционного лога на диск (синхронизация WAL). По умолчанию СУБД гарантирует абсолютную сохранность данных при внезапном отключении питания, из-за чего заставляет диск выполнять операцию физической записи при каждом коммите. Мы можем оптимизировать этот процесс:
# Разрешаем асинхронную запись транзакций.
# Это дает колоссальный прирост скорости записи!
# Риск: при жестком падении ОС (синий экран/выключение питания)
# могут быть потеряны последние 1-2 секунды транзакций, но база останется целостной.
synchronous_commit = off
# Метод синхронизации данных с диском (для ОС Windows наиболее быстрым часто является open_datasync)
wal_sync_method = open_datasync
# Защита от повреждения страниц данных при сбоях питания.
# Если у вас надежный сервер с RAID-контроллером с батарейкой (BBU) или качественный UPS,
# и вы регулярно делаете бэкапы, для тестовых баз можно отключить:
full_page_writes = off
3. Настройки оптимизатора и сбора статистики
Планировщик PostgreSQL должен правильно оценивать стоимость операций и собирать актуальную статистику по временным таблицам, которые активно использует расчет себестоимости 1С:
# Настройка стоимости случайного чтения для SSD (по умолчанию 4.0, что заставляет СУБД избегать индексов)
random_page_cost = 1.1
# Настройки лимита объединения таблиц. Обязательно оставьте значение по умолчанию!
# Установка join_collapse_limit = 1 ломает построение планов для запросов с RLS
join_collapse_limit = 8
# Глубина сбора статистики по таблицам (увеличение помогает планировщику точнее строить планы)
default_statistics_target = 1000
Также убедитесь, что в вашей сборке PostgreSQL для 1С подключены и настроены модули автоматического сбора статистики по временным таблицам на лету:
shared_preload_libraries = 'online_analyze, plantuner'
online_analyze.table_type = 'all'
online_analyze.enable = on
---
В процессе поиска решений на форумах часто можно встретить вредные советы, которые могут временно увеличить скорость, но приведут к катастрофическим последствиям:
fsync. Полное отключение fsync = off заставляет PostgreSQL полностью игнорировать требования операционной системы по записи данных на диск. При первом же сбое питания или зависании ОС ваша база данных превратится в «кашу» из нечитаемых файлов без возможности восстановления. Использовать данный параметр можно исключительно на временных тестовых базах, разворачиваемых «на один раз». На рабочих серверах используйте комбинацию безопасных параметров, описанных выше (например, synchronous_commit = off).join_collapse_limit до 1. Этот параметр часто советуют скрутить в единицу, чтобы заставить планировщик соединять таблицы строго в том порядке, в котором они написаны в запросе. Однако в конфигурациях с включенными механизмами разграничения прав доступа на уровне записей (RLS) этот параметр превратит открытие списков документов в бесконечное ожидание. СУБД не сможет оптимизировать сложные вложенные конструкции, генерируемые механизмами RLS. Держите этот параметр равным 8.---
Медленная запись в PostgreSQL при работе с 1С — это не приговор СУБД, а следствие несогласованности настроек платформы и конфигурации сервера. Для достижения производительности уровня MS SQL Server необходимо действовать комплексно:
Версия 8.3.8). Это уберет архитектурный оверхед платформы при работе с СУБД.postgresql.conf, уделив особое внимание кэшированию временных таблиц (temp_buffers) и асинхронному коммиту транзакций (synchronous_commit = off).Эти действия позволят вам получить стабильно работающую, быструю систему на базе бесплатного программного обеспечения, не уступающую по отзывчивости коммерческим аналогам.