Справочник системных ошибок и решений

Windows Server, Active Directory, 1С:Предприятие, СУБД, Linux, Cisco, MikroTik, Asterisk.

⚠️ Важная информация Все материалы, инструкции, команды и скрипты на сайте предоставлены исключительно в ознакомительных целях. Их применение может повлиять на работу операционной системы, программного обеспечения, баз данных, сетевого оборудования и других компонентов инфраструктуры. Перед выполнением действий создайте резервную копию и по возможности протестируйте изменения в безопасной среде. Пользователь самостоятельно оценивает риски и несет ответственность за результат. При отсутствии необходимых знаний обратитесь к квалифицированному ИТ-специалисту.

PG_AUTOVACUUM_LAG 1С:Предприятие и СУБД

Настройка параметров autovacuum в PostgreSQL под нагрузки 1С

Обновлено: 26.08.2026 · Официальная документация ↗
  • Разрастание (Table & Index Bloat) физического размера таблиц в 2-5 раз больше реального объема данных.
  • Деградация скорости чтения из-за необходимости сканирования «мертвых» строк (dead tuples).
  • Внезапные зависания базы при наступлении транзакционного зацикливания (Transaction ID Wraparound).

1. Проблема дефолтных настроек autovacuum для 1С

Платформа 1С генерирует миллионы временных записей при проведении документов и обновлении итогов регистров. Стандартный autovacuum в PostgreSQL настроен слишком консервативно и «засыпает» при дисковых ограничениях, не успевая очищать мертвые строки.

2. Оптимальная конфигурация postgresql.conf для 1С

# Включение и параллелизм автовакуума
autovacuum = on
autovacuum_max_workers = 6               # Количество параллельных потоков вакуума
autovacuum_naptime = 20s                 # Периодичность проверки таблиц

# Пороги срабатывания (более агрессивный запуск для 1С)
autovacuum_vacuum_threshold = 50
autovacuum_vacuum_scale_factor = 0.05    # 5% изменившихся строк вместо 20% по умолчанию
autovacuum_analyze_threshold = 50
autovacuum_analyze_scale_factor = 0.02   # 2% для сбора актуальной статистики

# Снятие ограничений по дисковой скорости (Cost Limit)
autovacuum_vacuum_cost_limit = 2000      # Увеличение лимита операций очистки (по умолчанию 200)
autovacuum_vacuum_cost_delay = 2ms       # Минимальная пауза между циклами

# Защита от Wraparound (заморозка старых транзакций)
autovacuum_freeze_max_age = 1000000000
vacuum_freeze_table_age = 800000000
vacuum_multixact_freeze_max_age = 1000000000

3. Мониторинг мертвых кортежей (Dead Tuples)

SELECT 
    relname,
    n_dead_tup,
    n_live_tup,
    round(n_dead_tup * 100 / (n_live_tup + n_dead_tup + 1),2) as dead_ratio,
    last_autovacuum
FROM pg_stat_user_tables
WHERE n_dead_tup > 10000
ORDER BY n_dead_tup DESC;
💡 Практика специалистов: Для таблиц итогов регистров накопления 1С с частой записью рекомендуется индивидуально переопределять scale_factor через ALTER TABLE _accumrg1234 SET (autovacuum_vacuum_scale_factor = 0.01), чтобы очистка запускалась непрерывно.

Частые вопросы (FAQ)

Почему нельзя полностью отключать autovacuum в PostgreSQL?

Отключение autovacuum гарантированно приведет к аварийной остановке PostgreSQL при достижении лимита транзакций (Wraparound) и катастрофическому разрастанию таблиц.

Что делать, если autovacuum создает слишком высокую нагрузку на диск в рабочее время?

Не отключайте вакуум, а увеличьте параметр autovacuum_vacuum_cost_delay до 10-20ms или перенесите тяжелые базы на быстрые NVMe SSD накопители.

Как запустить ручную очистку конкретной разросшейся таблицы 1С?

Выполните SQL-команду: VACUUM (ANALYZE, VERBOSE) _accumrg1234; (не блокирует чтение и запись).

Когда требуется выполнять VACUUM FULL?

VACUUM FULL требуется только после разового удаления гигантского объема данных (миллионов строк), так как он полностью блокирует таблицу эксклюзивным локом на время сжатия.

Полезные материалы
Рекомендуем