При активной работе пользователей в базах 1С, особенно в конфигурациях Управление торговлей 11 или ERP, в системных логах PostgreSQL часто можно встретить сообщение: ERROR: canceling autovacuum task. Чаще всего это происходит с таблицей _scheduledjobs. Разберем детально, почему это происходит, насколько это критично и как правильно настроить сервер, чтобы избежать раздувания (bloat) базы данных.
Проанализируем механизм работы СУБД. В PostgreSQL процесс autovacuum отвечает за очистку "мертвых" записей (dead tuples), которые остаются после операций UPDATE и DELETE. Однако этот процесс имеет самый низкий приоритет в системе. Рассмотрим две основные ситуации, когда задача прерывается:
TRUNCATE, DROP TABLE или изменения структуры ALTER TABLE), PostgreSQL немедленно убивает процесс autovacuum, чтобы не заставлять пользователей ждать. Таблица _scheduledjobs (регламентные задания) крайне активна: 1С постоянно пишет в нее статусы заданий и удаляет отработанные записи.deadlock_timeout, система принудительно завершает очистку.Сама по себе эта ошибка не является признаком падения базы, но если она повторяется постоянно, таблица перестает очищаться, начинает "раздуваться" (bloat), занимая лишнее место на диске и замедляя работу всей системы.
Посмотрим на типичные настройки, которые часто остаются "по умолчанию" (закомментированными) в файле postgresql.conf. При использовании 1С стандартные значения параметров autovacuum слишком консервативны. Разберем, что нужно изменить для сервера с 24 ГБ ОЗУ и процессором Core i7.
В обсуждениях часто упоминается завышенное количество соединений. Рассмотрим параметр max_connections. Если у вас 20-30 пользователей, значение в 700 соединений избыточно. Каждое соединение потребляет оперативную память.
Отредактируем следующие параметры в postgresql.conf:
# Уменьшаем количество соединений до разумного (количество сеансов + запас)
max_connections = 150
# Увеличиваем память для сервисных операций (индексы, vacuum)
# Стандартные 64MB — это очень мало для 24GB ОЗУ
maintenance_work_mem = 1GB
# Выделяем память под кэш данных (рекомендуется около 25% от всей ОЗУ)
shared_buffers = 6GB
Чтобы очистка успевала завершиться до того, как 1С ее "выбьет", нужно сделать autovacuum более быстрым и заставить его запускаться чаще. Проанализируем параметры секции AUTOVACUUM PARAMETERS:
vacuum_cost_limit (обычно 200). На современных SSD-дисках это значение можно смело увеличивать до 1000-2000, чтобы ускорить процесс.Пример рекомендуемых настроек:
autovacuum = on
autovacuum_max_workers = 4
autovacuum_naptime = 20s
autovacuum_vacuum_scale_factor = 0.01
autovacuum_analyze_scale_factor = 0.005
autovacuum_vacuum_cost_limit = 1000
Если ошибка canceling autovacuum task продолжает возникать именно на таблице _scheduledjobs, мы можем применить индивидуальные настройки для этой таблицы прямо из SQL-консоли (например, через pgAdmin), не перезагружая весь сервер.
Рассмотрим пример запроса для ускорения очистки конкретной таблицы:
ALTER TABLE trade.public._scheduledjobs35591 SET (
autovacuum_vacuum_scale_factor = 0.001,
autovacuum_vacuum_cost_delay = 0
);
Параметр autovacuum_vacuum_cost_delay = 0 заставляет процесс очистки работать без пауз на "отдых", что критически важно для максимально быстрого завершения задачи в "горячих" таблицах.
Проанализируем ситуацию с операционной системой. Использование Windows 10 Домашняя для сервера базы данных — не самое лучшее решение из-за ограничений на количество сетевых подключений и специфики работы планировщика потоков. Если сменить ОС невозможно, выполним следующие действия:
data) в исключения Защитника Windows и других антивирусов. Постоянное сканирование файлов БД при записи провоцирует задержки, из-за которых autovacuum не успевает вовремя освободить ресурсы.Если в течение дня логи показывают, что очистка так и не смогла завершиться успешно, необходимо настроить принудительное обслуживание. Выясним, когда в базе меньше всего пользователей (обычно это глубокая ночь).
Создадим задание в планировщике задач Windows, которое будет запускать скрипт очистки. Рассмотрим содержимое bat-файла:
"C:\Program Files\PostgreSQL\10\bin\vacuumdb.exe" -U postgres -d trade -t "public._scheduledjobs35591" -z -v
Команда VACUUM ANALYZE (ключ -z) полностью пересоберет карту свободных пространств и обновит статистику планировщика, что значительно ускорит выборку данных из этой таблицы в рабочее время.
Мы выяснили, что ошибка отмены задачи autovacuum — это защитный механизм PostgreSQL, предотвращающий ожидание пользователей 1С. Чтобы минимизировать негативные последствия, мы проделали следующие шаги:
maintenance_work_mem, чтобы очистка проходила за один проход в памяти.scale_factor, чтобы autovacuum приходил чаще и обрабатывал меньшие порции данных.cost_limit, сняв искусственное ограничение скорости работы процесса.Соблюдение этих рекомендаций позволит поддерживать базу данных в компактном состоянии и избежать деградации производительности регламентных заданий 1С.