Оптимизация PostgreSQL для 1С:Предприятие 8.3

Когда мы говорим о 1С:Предприятие 8.3 и PostgreSQL, важно понимать, что нагрузка здесь совсем не такая, как у обычных веб-приложений. Она очень специфична:

• Массовые временные таблицы — 1С активно использует временные таблицы для промежуточных вычислений
• Длинные транзакции — проведение документов может занимать секунды и минуты
• Сложные запросы — СКД и отчёты генерируют запросы с десятками JOIN
• Высокий write-load — частые UPDATE при записи регистров
• Большие BLOB — хранение файлов и макетов в базе

Знаете, фирма «1С» не просто так выпускает свою сборку PostgreSQL – она специально патчена и оптимизирована под их платформу. И вот что я вам скажу: именно её и стоит использовать, а не голый, «ванильный» PostgreSQL. Скачать её можно прямо с releases.1c.ru. Кстати, сейчас поддерживаются версии PostgreSQL 14, 15, 16, конечно же, с патчами от 1С.

Оптимизация идёт на трёх уровнях: конфигурация PostgreSQL, настройка ОС и оптимизация самой базы 1С.

Правильная настройка памяти — это фундамент производительности. Ключевые параметры в postgresql.conf:

# Общий буфер — 25% от RAM сервера, но не более 8 ГБ
# Для сервера с 32 ГБ RAM:
shared_buffers = 8GB

# Рабочая память для сортировки и хеширования
# Важно: выделяется на КАЖДУЮ операцию, не на соединение
work_mem = 256MB

# Для операций обслуживания (VACUUM, CREATE INDEX)
maintenance_work_mem = 2GB

# Буфер WAL — для 1С рекомендуется увеличить
wal_buffers = 64MB

# Эффективный размер кеша (подсказка планировщику)
# 75% от RAM
effective_cache_size = 24GB

# Кеш для временных таблиц (критично для 1С!)
temp_buffers = 256MB

Важно: параметр work_mem влияет на каждую операцию сортировки/хеширования. При 100 одновременных пользователях 1С и work_mem = 256MB потенциальное потребление: 100 × 256 МБ × несколько операций. Мониторьте использование памяти и корректируйте.

Write-Ahead Log (WAL) — критичный компонент для производительности записи. 1С генерирует большой объём WAL при проведении документов.

# Размер сегмента WAL
wal_segment_size = 16MB

# Целевой размер WAL между checkpoint
max_wal_size = 4GB
min_wal_size = 1GB

# Разнесение checkpoint по времени (снижает пики I/O)
checkpoint_completion_target = 0.9
checkpoint_timeout = 15min

# Уровень WAL для надёжности
wal_level = replica

# Синхронная запись WAL — включена для надёжности
synchronous_commit = on

# Сжатие WAL (снижает I/O)
wal_compression = on

Для SSD-хранилищ с хорошей производительности записи увеличьте max_wal_size до 8 ГБ — это уменьшит частоту checkpoint и снизит пиковые нагрузки на диск.

1С даёт высокую нагрузку UPDATE на регистры, а это быстро копит dead tuples. Стандартный autovacuum с таким темпом не справляется:

# Количество воркеров (для 1С рекомендуется больше)
autovacuum_max_workers = 6

# Порог запуска — чаще для горячих таблиц
autovacuum_vacuum_threshold = 50
autovacuum_vacuum_scale_factor = 0.02  # 2% вместо 20%

# Анализ — чаще для актуальной статистики планировщика
autovacuum_analyze_threshold = 50
autovacuum_analyze_scale_factor = 0.01  # 1%

# Агрессивность — для SSD можно убрать задержку
autovacuum_vacuum_cost_delay = 2ms
autovacuum_vacuum_cost_limit = 1000

# Заморозка
vacuum_freeze_min_age = 5000000
vacuum_freeze_table_age = 150000000

Для регистров накопления и сведений с частым UPDATE настройте индивидуальные параметры:

-- Для таблицы регистра с частыми UPDATE
ALTER TABLE _accumrgt1234 SET (
    autovacuum_vacuum_scale_factor = 0.005,
    autovacuum_vacuum_cost_delay = 0
);

Найдите «горячие» таблицы 1С:

SELECT relname, n_tup_upd, n_tup_del, n_dead_tup,
       round(n_dead_tup::numeric / NULLIF(n_live_tup, 0) * 100, 1) AS dead_pct,
       last_autovacuum
FROM pg_stat_user_tables
ORDER BY n_dead_tup DESC
LIMIT 20;

Планировщик PostgreSQL не всегда корректно оценивает стоимость запросов 1С из-за коррелированных данных и неравномерного распределения. Ключевые параметры:

# Стоимость случайного чтения
# Для SSD — снижаем (SSD быстрее случайного чтения)
random_page_cost = 1.1  # по умолчанию 4.0
seq_page_cost = 1.0

# Стоимость операций CPU
cpu_tuple_cost = 0.01
cpu_index_tuple_cost = 0.005
cpu_operator_cost = 0.0025

# Улучшенная оценка через расширенную статистику
default_statistics_target = 200  # по умолчанию 100

# Включить JIT-компиляцию для сложных запросов
jit = on
jit_above_cost = 100000
jit_inline_above_cost = 500000

Для диагностики медленных запросов включите логирование:

# Логировать запросы медленнее 5 секунд
log_min_duration_statement = 5000

# Логировать планы выполнения
log_statement = 'none'  # 'all' для отладки, 'none' для продакшена

# Расширение pg_stat_statements — обязательно для 1С
shared_preload_libraries = 'pg_stat_statements'
pg_stat_statements.max = 10000
pg_stat_statements.track = all

ОС должна быть оптимизирована для PostgreSQL. Основные настройки для Linux:

# /etc/sysctl.d/99-postgresql.conf

# Управление swappiness — минимизируем использование swap
vm.swappiness = 1

# Dirty pages — чаще сбрасываем на диск, но меньшими порциями
vm.dirty_ratio = 10
vm.dirty_background_ratio = 3

# Размер очереди readahead для SSD (меньше для SSD)
vm.zone_reclaim_mode = 0

# Увеличение лимитов IPC для shared memory
kernel.shmmax = 17179869184  # 16GB
kernel.shmall = 4194304

# Сетевые настройки (для удалённых подключений)
net.core.somaxconn = 1024
net.ipv4.tcp_keepalive_time = 300

Настройка планировщика I/O для SSD:

# Проверить текущий планировщик
cat /sys/block/sda/queue/scheduler

# Установить none/noop для SSD
echo "none" > /sys/block/sda/queue/scheduler

# Постоянно через udev-правило
echo 'ACTION=="add|change", KERNEL=="sd*", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="none"' > /etc/udev/rules.d/60-ssd-scheduler.rules

Не всё решается настройками PostgreSQL — часть проблем в конфигурации 1С:

Регламентные задания:

• Разнесите тяжёлые регламентные задания (обновление итогов, пересчёт) на нерабочие часы
• Закрытие месяца запускайте в окне обслуживания

Реструктуризация базы:

-- Выполните через pgAdmin или psql:
REINDEX DATABASE "base1c";
ANALYZE;

Тестирование и исправление базы (через конфигуратор 1С):

1. Администрирование → Тестирование и исправление
2. Отметьте: Реиндексация таблиц, Пересчёт итогов, Сжатие таблиц
3. Выполняйте на остановленной базе в нерабочее время

Мониторинг технологического журнала 1С:

Создайте файл logcfg.xml в каталоге conf рабочего сервера:

<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="/var/log/1c/techlog" history="24">
    <event>
      <eq property="name" value="DBPOSTGRS"/>
      <ge property="duration" value="5000000"/>
    </event>
    <property name="all"/>
  </log>
</config>

Это логирует все обращения к PostgreSQL дольше 5 секунд, позволяя найти проблемные операции.

Самые частые проблемы производительности 1С на PostgreSQL:

Проблема 1: «Блокировки при проведении документов».

-- Найти блокировки
SELECT blocked.pid AS blocked_pid,
       blocked.query AS blocked_query,
       blocking.pid AS blocking_pid,
       blocking.query AS blocking_query
FROM pg_stat_activity blocked
JOIN pg_locks bl ON bl.pid = blocked.pid AND NOT bl.granted
JOIN pg_locks gr ON gr.locktype = bl.locktype 
    AND gr.database = bl.database AND gr.relation = bl.relation 
    AND gr.page = bl.page AND gr.tuple = bl.tuple AND gr.granted
JOIN pg_stat_activity blocking ON blocking.pid = gr.pid;

Решение: оптимизируйте код проведения документов, используйте регистр накопления вместо сведений для высоконагруженных операций.

Проблема 2: «Медленные отчёты СКД».

Причина — отсутствие индексов. Заведите индексы на часто фильтруемые поля:

-- Для регистра накопления Продажи, фильтр по номенклатуре
CREATE INDEX CONCURRENTLY idx_sales_nomenclature 
    ON _accumrg1234 (_fld5678);

-- Для справочника Контрагенты, поиск по ИНН
CREATE INDEX CONCURRENTLY idx_partner_inn 
    ON _reference123 (_fld456);

Проблема 3: «Медленный запуск базы по утрам»

Причина — холодный кеш после ночи. Лечится прогревом кеша:

CREATE EXTENSION pg_prewarm;

-- Прогрев основных таблиц после рестарта
SELECT pg_prewarm('_accumrg1234');  -- регистры
SELECT pg_prewarm('_reference567');  -- справочники