Работа с базами 1С на PostgreSQL

26 февраля 2026

Работа с базами 1С на PostgreSQL объёмом свыше 100 ГБ требует перехода от базовых настроек к профессиональному администрированию СУБД. В статье рассмотрим типичные проблемы, возникающие при работе с большими базами, и способы их решения — от настройки производительности до миграции и архивации данных.


Проблемы больших баз и их решение

При росте базы данных возникают характерные проблемы:

  • Разрастание таблиц и медленные запросы
  • Нехватка оперативной памяти и дисковых операций (I/O)
  • Блокировки при операциях обслуживания
  • Переполнение транзакционного журнала (WAL)

Решения включают:

  • Регулярное обслуживание (REINDEX/VACUUM)
  • Перенос временных файлов на NVMe-диски
  • Настройку параметров PostgreSQL под нагрузку
  • Партиционирование таблиц для архивации данных

Свертка базы: когда PostgreSQL не справляется

Автоматическая свертка 1С:УНФ на PostgreSQL часто вызывает проблемы:

  • Ошибки pg_dump или таймауты из-за большого объема данных
  • «Недостаточно места» при переполнении WAL-журнала
  • Зависание на удалении данных из-за нехватки ресурсов

Что делать если автоматическая свертка не работает:

  1. Создавайте бэкап вручную через Конфигуратор или pg_dump
  2. Выполняйте свертку без создания резервной копии
  3. Удаляйте данные поэтапно (помесячно или поквартально)
  4. Очищайте таблицу Config при ошибках обновления
  5. Настройте параметры PostgreSQL (max_connections, место для pg_wal)

Нюанс: При автоматической свертке возникают блокировки таблицы Config, которые приводят к таймаутам pg_dump.

Решение:

  • Выполняйте свертку вручную через Конфигуратор
  • Используйте флаг «без создания резервной копии» в обработке свертки
  • Разбивайте удаление помеченных объектов на части:

-- Удаление данных поквартально
DELETE FROM таблица WHERE marked = true
AND date < '2023-01-01' LIMIT 100000;
-- Повторять с увеличением даты

Важный нюанс: Размер WAL (транзакционного журнала) при удалении миллионов записей может превысить доступное место. Решение — увеличить pg_wal до 20-40 ГБ и настроить мониторинг.

Настройка производительности PostgreSQL для 1С

Поиск медленных запросов

pg_stat_statements — модуль для отслеживания статистики выполнения SQL-запросов:

SELECT * FROM pg_stat_statements ORDER BY total_time DESC;

auto_explain — запись планов выполнения медленных запросов (настраивается через log_min_duration).

Тюнинг индексов

Поиск отсутствующих индексов:

SELECT relname, seq_scan - idx_scan AS too_much_seq,
CASE WHEN seq_scan - coalesce(idx_scan, 0) > 0
THEN 'Missing Index?' ELSE 'OK' END,
pg_relation_size(relname::regclass) AS rel_size,
seq_scan, idx_scan
FROM pg_stat_all_tables
WHERE schemaname = 'public'
AND pg_relation_size(relname::regclass) > 80000
ORDER BY too_much_seq DESC;

Поиск неиспользуемых индексов:

SELECT indexrelid::regclass as index, relid::regclass as table,
'DROP INDEX ' || indexrelid::regclass || ';' as drop_statement
FROM pg_stat_user_indexes
JOIN pg_index USING (indexrelid)
WHERE idx_scan = 0 AND indisunique is false;

Ключевые настройки PostgreSQL для 1С

  • shared_buffers: 25-40% от ОЗУ
  • effective_cache_size: 50-75% от ОЗУ
  • work_mem: 16-64 МБ (в зависимости от числа соединений)
  • maintenance_work_mem: до 1 ГБ для обслуживания
  • synchronous_commit = off: ускорение записи (риск потери последних транзакций)
  • random_page_cost = 1.1-2.0: для SSD-дисков
  • Автоочистка: настройте агрессивный autovacuum для больших баз

Миграция больших баз 1С на PostgreSQL

Ограничения и реалии

Хотя формально размер DT-файла не ограничен, на практике:

  • База 1.7 ТБ выгружается за 14 часов в DT-файл 55 ГБ
  • Загрузка занимает примерно столько же времени
  • Для баз более 2 ТБ может потребоваться несколько суток

Подготовка к миграции

  1. Очистка итогов — сокращает объем выгружаемых данных
  2. Настройка оборудования:
    • RAID 10 предпочтительнее RAID 5 (больше IOPS)
    • Сеть 10 GbE или агрегация каналов
    • Достаточный объем временного хранилища на сервере 1С (до 20 ГБ и более)

  1. Настройка PostgreSQL-приемника:

    • synchronous_commit = off (для ускорения загрузки)
    • fsync = on (обязательно для сохранения целостности)

Новый метод миграции

В версии 8.3.23 появилась возможность миграции без выгрузки в DT-файл:

ibcmd infobase replicate --data=d:\data --dbms=MSSQLServer \
--database-server=localhost --database-name=dbMsSql \
--target-dbms=PostgreSQL --target-database-server=localhost \
--target-database-name=dbPgSql --target-create-database

Архивация и ротация данных

Для больших баз 1С (VLDB)

  • Партиционирование таблиц по времени (месяц, квартал)
  • Отсоединение старых партиций (DETACH PARTITION)
  • Экспорт через pg_dump с последующим сжатием
  • Настройка WAL-архивации для восстановления на момент времени

Для NetFlow и потоковых данных

  • Автоматическое партиционирование по дням/неделям
  • Удаление старых партиций через DROP TABLE
  • Использование pg_cron для автоматизации очистки
  • Индексы только на активных партициях

Практические рекомендации по оптимизации

Аппаратный уровень

  • SSD/NVMe диски обязательны для баз 1С
  • Оперативная память: минимум 8 ГБ на клиенте, 64+ ГБ на сервере
  • Сеть: 10 GbE между серверами
  • Процессор: высокая частота важнее количества ядер

Программный уровень

  1. Регулярное обслуживание:

    • Тестирование и исправление в Конфигураторе
    • Пересчет итогов в фоновом режиме
    • Обновление статистики (ANALYZE)

  1. Оптимизация запросов:

    • Избегайте запросов в циклах
    • Используйте виртуальные таблицы
    • Правильно применяйте индексы
    • Преобразуйте подзапросы в JOIN

  1. Настройка 1С:

    • Отключение ненужных фоновых заданий
    • Настройка RLS для уменьшения нагрузки
    • Использование последних версий платформы

Прочие проблемы и нюансы:

1. Проблема OOM Killer в Linux


PostgreSQL убивается OOM Killer при нехватке памяти.

Решение:

# В /etc/sysctl.conf
vm.overcommit_memory = 2
vm.overcommit_ratio = 95
# В /etc/systemd/system/postgresql.service.d/oom.conf
[Service]
OOMScoreAdjust=-1000

Важный нюанс: Не все процессы PostgreSQL должны иметь одинаковый OOM-приоритет. Основной процесс должен иметь высокий приоритет, а воркеры — низкий.

2.Нюансы статистики и планов выполнения

Проблема: На dev-окружении запросы работают быстро, а на prod — медленно.

Причины и решения:

Ситуация Причина Решение
Разный объем данных PostgreSQL выбирает Seq Scan вместо Index Scan на маленьких таблицах Включить SET enable_seqscan = OFF в dev или использовать pgbench для генерации реалистичных данных
Разная память Hash Join невозможен при недостатке work_mem Настроить work_mem пропорционально нагрузке: work_mem = (RAM * 0.25) / max_connections
Устаревшая статистика Неверные оценки оптимизатора Агрессивный autovacuum: autovacuum_vacuum_scale_factor = 0.01, autovacuum_analyze_scale_factor = 0.005
   

3.Нюансы миграции больших баз

Скрытая проблема: При миграции через DT теряется информация о табличных пространствах (tablespace).

Решение для баз > 2 ТБ:

  1. Перед миграцией в Postgres создать tablespace для данных и индексов:

CREATE TABLESPACE v81c_data LOCATION '/ssd1/postgres/data';
CREATE TABLESPACE v81c_index LOCATION '/ssd2/postgres/index';

  1. После загрузки DT пересоздать индексы в нужном tablespace:

-- Для каждого индекса
CREATE INDEX CONCURRENTLY новый_индекс ON таблица(поле)
TABLESPACE v81c_index;
DROP INDEX старый_индекс;

Нюанс времени: Пересчет итогов в PostgreSQL работает в 3-5 раз медленнее, чем в MS SQL. Решение — делать пересчет параллельно и постепенно.

4. Нюансы обновления платформы 1С

  

Проблема: После обновления платформы меняются шаблоны запросов, что может привести к деградации производительности.

Процедура безопасного обновления:

  1. Перед обновлением снять статистику pg_stat_statements
  2. После обновления сравнить планы выполнения ключевых запросов
  3. При необходимости перестроить проблемные индексы:

-- Перестроение индекса с изменением fillfactor
REINDEX INDEX CONCURRENTLY индекс_таблицы;
ALTER INDEX индекс_таблицы SET (fillfactor = 90);

Экстренные меры при проблемах

При зависании свертки:

  1. Найти и убить блокирующие процессы:

SELECT pg_terminate_backend(pid)
FROM pg_locks WHERE relation = 'config'::regclass;

  1. Временно увеличить max_locks_per_transaction
  2. Выполнить свертку через автономный сервер 1С

При нехватке места в WAL:

-- Срочное освобождение места
SELECT pg_switch_wal(); -- PostgreSQL 10+
CHECKPOINT;

При деградации производительности:

  1. Включить экстренный vacuum:

VACUUM (VERBOSE, ANALYZE) проблемная_таблица;

  1. Перестроить проблемные индексы:

REINDEX TABLE проблемная_таблица;

Профилактика проблем

  1. Регулярные проверки:

    • Еженедельно: pg_stat_user_tables на предмет bloat
    • Ежемесячно: пересчет статистики для больших таблиц
    • Ежеквартально: полный reindex критических таблиц

  1. Резервирование ресурсов:

    • 20% свободного места на дисках с WAL
    • 10% свободной памяти для пиковых нагрузок
    • Резервная сетевая инфраструктура

  1. Документирование специфики:

    • Ведение журнала изменений производительности после обновлений
    • Карта зависимостей таблиц 1С для оптимизации JOIN
    • Шаблоны проблемных запросов для ускорения диагностики


Администрирование больших баз 1С на PostgreSQL требует комплексного подхода: от грамотной настройки СУБД до оптимизации запросов и правильного планирования миграций. Ключевые факторы успеха — регулярное обслуживание, правильная архивация данных и постоянный мониторинг производительности.

Современные версии 1С и PostgreSQL предоставляют инструменты для эффективной работы с терабайтными базами, но их использование требует профессиональных знаний и тщательного планирования операций.




Подписаться на рассылку: Новости Софт-портал



Вернуться к списку