При обновлении платформы 1С:Предприятие до версий 8.3.17.х или 8.3.18.х многие системные администраторы сталкиваются с неприятной особенностью: логи PostgreSQL начинают стремительно расти, заполняясь однотипными сообщениями вида LOG: fast-truncating relation pg_temp.tt... и STATEMENT: SELECT FASTTRUNCATE ('pg_temp.tt...'). В некоторых случаях объем логов может исчисляться гигабайтами в час, что создает избыточную нагрузку на дисковую подсистему и процессор.
В этой статье мы подробно разберем, почему это происходит, за что отвечает функция FASTTRUNCATE, и какими способами можно остановить этот «спам» в логах, сохранив при этом производительность системы.
Для начала проанализируем ситуацию с технической точки зрения. Модуль fasttrun — это специальное расширение, разработанное компанией Postgres Professional специально для оптимизации работы 1С. Основная его задача — предотвратить разрастание системных каталогов PostgreSQL (таких как pg_class и pg_attribute) при активном использовании временных таблиц.
Ранее, при использовании обычных команд DROP TABLE или TRUNCATE, PostgreSQL каждый раз обновлял метаданные, что приводило к «распуханию» (bloat) базы данных и замедлению всех запросов. Функция FASTTRUNCATE выполняет очистку временной таблицы без удаления её записи из системного каталога, просто обнуляя файл данных на диске.
Почему проблема проявилась именно сейчас? Начиная с версии платформы 8.3.17, механизмы работы с временными таблицами были изменены. Платформа стала гораздо агрессивнее использовать переиспользование временных таблиц в рамках одного сеанса. Вместо того чтобы удалять таблицу, 1С дает команду на её быструю очистку. В сочетании со старыми сборками PostgreSQL (9.6, 10, 11), где уровень логирования этой операции был жестко зашит как LOG, это приводит к бесконечному потоку сообщений.
Самый правильный и «чистый» способ решения проблемы — переход на более современные версии СУБД. Рассмотрим, почему это помогает:
fasttrun. Сообщения об успешной очистке больше не сыплются в лог на уровне LOG по умолчанию.Если вы используете версию 9.6, которая уже снимается с поддержки, крайне рекомендуется запланировать миграцию на актуальный релиз от Postgres Pro или другие оптимизированные под 1С сборки.
Если оперативно обновить СУБД невозможно, попробуем изменить настройки конфигурации PostgreSQL. Разберем по шагам, какие параметры на это влияют.
Многие пытаются установить параметр log_statement = 'none', но, как показывает практика, это не помогает убрать строки LOG: fast-truncating.... Это происходит потому, что расширение fasttrun выдает сообщение напрямую через внутренние механизмы сервера, минуя фильтр log_statement.
Чтобы действительно скрыть эти сообщения, необходимо изменить параметр log_min_messages. По умолчанию он обычно установлен в warning или notice, но в некоторых сборках 1С-ный PostgreSQL форсирует уровень LOG.
Попробуйте установить следующие значения в файле postgresql.conf:
# Устанавливаем минимальный уровень сообщений для записи в лог
log_min_messages = warning
# Также стоит проверить настройки на стороне клиента (необязательно)
client_min_messages = error
Важное предупреждение: Установка уровня warning скроет не только спам от временных таблиц, но и другие информационные сообщения (например, данные о завершении контрольных точек или работе автовакуума). Используйте этот метод осторожно, если вам важен детальный мониторинг состояния базы.
Если проблема не только в размере файлов логов, но и в нагрузке на дисковую систему (IOPS), которую генерирует создание и очистка тысяч мелких временных таблиц, стоит рассмотреть вариант использования tmpfs.
Проанализируем ситуацию: временные таблицы в PostgreSQL хранятся в специальном табличном пространстве. Мы можем перенести их в оперативную память. Для Linux-систем это делается следующим образом:
mkdir /var/lib/pgsql/pg_tmp_ramtmpfs: mount -t tmpfs -o size=2G tmpfs /var/lib/pgsql/pg_tmp_ramTABLESPACE, указывающий на эту папку.postgresql.conf: temp_tablespaces = 'имя_вашего_tablespace'Это не уберет записи из логов, но снимет физическую нагрузку с ваших SSD/HDD дисков, так как все операции FASTTRUNCATE будут происходить в RAM.
Если ваша СУБД настроена на передачу логов в syslog, вы можете отфильтровать ненужные строки средствами операционной системы, не меняя уровень детализации самого PostgreSQL. Это позволит видеть важные сообщения уровня LOG, но игнорировать конкретно FASTTRUNCATE.
В конфигурационном файле rsyslog можно добавить правило, которое будет искать паттерн текста и отбрасывать его (~ или stop):
:msg, contains, "fast-truncating relation" ~
:msg, contains, "SELECT FASTTRUNCATE" ~
После внесения изменений не забудьте перезапустить службу логгера. Это «хирургический» способ, который сохранит чистоту ваших журналов без вреда для информативности диагностики.
Мы рассмотрели проблему избыточного логирования при совместной работе 1С 8.3.18 и PostgreSQL. Подведем итоги:
fasttrun в старых версиях СУБД.log_min_messages до уровня warning, однако это снизит информативность логов.tmpfs, если объем оперативной памяти позволяет выделить 2-4 ГБ под эти нужды.Также обратите внимание на часовой пояс в ваших логах (например, EDT). Если он не совпадает с вашим реальным временем, проверьте параметры log_timezone и timezone в postgresql.conf, чтобы при анализе инцидентов вам было проще сопоставлять данные из логов СУБД и технологического журнала 1С.