При переходе с MS SQL на PostgreSQL в рамках импортозамещения многие сталкиваются с неожиданным падением производительности, особенно на операциях записи и проведения документов. Ситуация, когда мощный сервер с PostgreSQL показывает результаты в десятки раз хуже, чем старый сервер на MS SQL, является типичной и требует комплексного подхода к решению. Простого "переключения" СУБД недостаточно; необходима тщательная настройка как самой базы данных, так и анализ работы платформы 1С.
Разберем по шагам, в какую сторону двигаться, чтобы выявить причину низкой скорости и оптимизировать работу системы.
Прежде чем погружаться в тонкие настройки СУБД, убедимся, что наша основа заложена правильно. Правильное проектирование защищенной инфраструктуры — залог стабильной работы, ведь часто проблемы кроются в самых очевидных вещах.
noop или deadline. Проверьте настройки гипервизора: нет ли искусственных ограничений по IOPS (операциям ввода-вывода в секунду) или по использованию процессорных мощностей для виртуальной машины с СУБД.
Производительность PostgreSQL на 90% зависит от корректных настроек в файле postgresql.conf. Настройки по умолчанию рассчитаны на слабые машины и абсолютно не подходят для мощных серверов. Проанализируем ключевые параметры.
Важно: перед внесением изменений всегда делайте резервную копию файла postgresql.conf, а также настройте регулярное архивирование баз данных PostgreSQL.
shared_buffers: Основной кэш данных PostgreSQL. Это самый важный параметр. Рекомендуемое значение — 25% от общего объема оперативной памяти (RAM) сервера. Например, для сервера с 256 ГБ ОЗУ следует установить shared_buffers = 64GB.
effective_cache_size: Подсказка для планировщика PostgreSQL о том, сколько памяти доступно для кэширования данных в целом (включая кэш ОС). Рекомендуемое значение — 50-75% от общего объема RAM. Для 256 ГБ сервера можно установить effective_cache_size = 192GB.
maintenance_work_mem: Объем памяти для служебных операций (создание индексов, `VACUUM`). Увеличение этого параметра значительно ускоряет эти операции. Рекомендуемое значение — 1-2 ГБ. Например, maintenance_work_mem = 2GB.
work_mem: Память, выделяемая на одну операцию сортировки или хэширования в рамках запроса. Если значение слишком маленькое, PostgreSQL будет сбрасывать временные данные на медленный диск. Начинать можно со значений 32-64MB и увеличивать, анализируя планы запросов. Не устанавливайте это значение слишком высоким, так как оно выделяется на каждую операцию, и при большом количестве одновременных подключений может быстро исчерпать всю память.
max_wal_size: Максимальный размер файлов журнала транзакций. Увеличивая его, мы реже вызываем `checkpoint` (массовый сброс "грязных" страниц на диск), что снижает пиковые нагрузки на дисковую подсистему. Для систем с интенсивной записью можно установить 32GB или даже 64GB.checkpoint_timeout: Максимальный временной интервал между `checkpoint`. Рекомендуется увеличить до 15-30 минут (15min).checkpoint_completion_target: Сглаживает процесс записи `checkpoint` во времени. Значение 0.9 является оптимальным, "размазывая" запись на 90% времени между `checkpoint`.synchronous_commit = off: Этот параметр дает огромный прирост производительности на запись. Он отключает ожидание подтверждения записи WAL на диск перед тем, как вернуть клиенту ответ об успешной транзакции. ВНИМАНИЕ: использование этого параметра создает риск потери последних нескольких транзакций при внезапном падении сервера. Для тестовых сред это приемлемо, для продуктивных — используйте с осторожностью, осознавая риски.
random_page_cost: Стоимость чтения случайной страницы с диска. Для быстрых SSD-дисков это значение следует понизить со стандартного 4.0 до 1.1 - 1.5.effective_io_concurrency: Количество одновременных операций ввода-вывода, которые может выполнять система. Для современных SSD-массивов можно устанавливать значения 100-300.autovacuum_vacuum_scale_factor и autovacuum_analyze_scale_factor.
Для первоначальной настройки можно воспользоваться онлайн-калькуляторами типа pgtune, которые сгенерируют базовый конфиг на основе параметров вашего сервера.
Если после настройки сервера производительность все еще низкая, скорее всего, проблема кроется в самих запросах. MS SQL и PostgreSQL — это разные СУБД с разными оптимизаторами. Запрос, который отлично работает на одной, может быть крайне медленным на другой.
postgresql.conf установите параметр log_statement = 'all' для временной диагностики. Это позволит увидеть все запросы, которые платформа 1С отправляет в базу данных во время проведения документа.
EXPLAIN ANALYZE. Это главный инструмент для анализа производительности запросов. Найдя медленный запрос в логах, выполните его в консоли psql, добавив в начало EXPLAIN ANALYZE. Вывод покажет детальный план выполнения: какие таблицы сканируются, какие индексы используются (и используются ли вообще), где тратится больше всего времени. Ищите в плане "узкие места", такие как Seq Scan (полное сканирование) на больших таблицах, где ожидался Index Scan.
pg_stat_statements. Это расширение собирает статистику по всем выполняемым запросам, позволяя найти самые "тяжелые" и часто выполняемые из них.
JOIN (SELECT ...)).Важно понимать, что тест "перезапись документов Больничный лист" — это не простая операция. Конфигурация "Зарплата и управление персоналом" известна сложными алгоритмами расчетов.
Проведение одного документа может инициировать десятки запросов к базе: чтение данных из множества регистров, сложные вычисления и, наконец, запись движений в несколько других регистров. Как было отмечено в обсуждении, один документ может вызывать 5 записей движений и 24 запроса к регистрам.
Многократное падение производительности может быть вызвано всего одним неэффективным планом для одного из этих 24 запросов. Именно поэтому так важен анализ запросов с помощью EXPLAIN ANALYZE.
Использование флага ОбменДанными.Загрузка = Истина упрощает тест, отключая часть бизнес-логики, но не меняет основной схемы взаимодействия с базой данных при записи движений. Проблема неэффективности запросов при этом сохраняется.
Переход 1С с MS SQL на PostgreSQL — это не просто смена СУБД, а полноценный проект по миграции, требующий внимания к деталям. Начните с проверки базовых условий (сборка от 1С, совместимость версий). Затем переходите к тщательной настройке postgresql.conf под ваше "железо". Если проблема сохраняется, погружайтесь в анализ медленных запросов с помощью инструментов PostgreSQL. Скорее всего, корень проблемы кроется в комбинации недостаточной настройки СУБД и неоптимальных планов выполнения для сложных запросов, генерируемых платформой 1С.