При администрировании баз данных 1С на платформе PostgreSQL многие сталкиваются с повышенной нагрузкой на дисковую подсистему. В официальной документации к старым версиям СУБД содержится рекомендация: разместить каталог временной статистики stats_temp_directory в файловой системе в оперативной памяти (ОЗУ). Разберем подробно, что именно означает этот параметр, как правильно настроить хранилище в оперативной памяти, с какими подводными камнями можно столкнуться и как обстоят дела в современных релизах PostgreSQL.
Выясним причину высокой нагрузки. В архитектуре баз данных 1С создаются тысячи служебных таблиц, реквизитов и индексов. В версиях PostgreSQL до 14 включительно сбор кумулятивной статистики (информация о чтениях, транзакциях, сканированиях таблиц и строк) возлагался на отдельный процесс сборщика статистики — pgstat collector.
Этот процесс принимал метрики по UDP-каналу и периодически (по умолчанию примерно каждые 500 мс при активной работе пользователей) целиком перезаписывал файлы со снимком текущей статистики в каталог pg_stat_tmp. В типовых базах 1С объем таких файлов может достигать сотен мегабайт. Постоянная перезапись сотен мегабайт данных дважды в секунду приводит к непрерывной паразитной нагрузке на накопители, ускоренному износу твердотельных дисков (TBW) и конкуренции за операции ввода-вывода с реальными транзакциями пользователей.
Проанализируем распространенное заблуждение: попытку связать параметр stats_temp_directory с файлом подкачки операционной системы (swap в Linux или pagefile в Windows). Направление каталога на диск с файлом подкачки не имеет никакого отношения к оперативной памяти. Файловые операции со статистикой в таком случае продолжат выполняться на физическом накопителе, создавая ту же нагрузку.
Под размещением целевого каталога в ОЗУ документация подразумевает создание специальной файловой системы, физически расположенной в оперативной памяти (RAM-диск или tmpfs).
Разберем по шагам, как вынести каталог stats_temp_directory в оперативную память на серверах под управлением Linux. Для этого используется виртуальная файловая система tmpfs.
Обратите внимание: простого добавления записи в /etc/fstab зачастую недостаточно. При перезагрузке операционной системы права на смонтированную директорию могут сброситься, из-за чего служба СУБД завершится с ошибкой запуска. Настроим каталог правильно через механизм systemd-tmpfiles:
/etc/tmpfiles.d/postgresql-stat.conf, который гарантирует создание точки монтирования с нужными правами владельца postgres:
d /var/run/postgresql/pg_stat_tmp 0750 postgres postgres -
systemd-tmpfiles --create /etc/tmpfiles.d/postgresql-stat.conf
postgresql.conf и укажем путь к созданному каталогу в ОЗУ:
stats_temp_directory = '/var/run/postgresql/pg_stat_tmp'
Посмотрим на специфику работы под Windows. В этой операционной системе нет встроенного механизма монтирования tmpfs, поэтому приходится прибегать к стороннему программному обеспечению для организации RAM-дисков.
Однако здесь существуют критические системные ограничения:
NetworkService или выделенный локальный пользователь postgres). Большинство пользовательских утилит для RAM-дисков монтируют виртуальный том только для текущей сессии рабочего стола, и служба базы данных попросту не увидит этот диск.stats_temp_directory, и аварийно остановится.В связи с этим использование RAM-дисков под Windows в промышленной эксплуатации баз 1С не рекомендуется из-за низкой стабильности решения.
Рассмотрим, как данная проблема решена в современных релизах платформы. Начиная с PostgreSQL 15, параметр stats_temp_directory был полностью удален разработчиками движка СУБД.
Архитектура коллектора статистики была кардинально переработана: отдельный процесс сброса статистики на диск упразднен. Теперь вся оперативная статистика ведется непосредственно в разделяемой оперативной памяти (shared memory). Если вы используете актуальные версии PostgreSQL (15, 16 или новее) в связке с 1С, настраивать RAM-диски и искать этот параметр больше не требуется — проблема дискового износа статистикой устранена на уровне ядра СУБД.
Если цель состоит в общем снижении нагрузки на накопители и увеличении производительности баз 1С, рассмотрим альтернативные системные настройки параметров PostgreSQL:
checkpoint_completion_target = 0.9 и увеличим max_wal_size (до 16–32 ГБ и выше в зависимости от объема базы), чтобы контрольные точки выполнялись реже и без пиковых зависаний дисковой очереди.pg_wal на отдельном физическом накопителе. Это разделит последовательные операции записи транзакций и случайные операции чтения/записи основных таблиц базы 1С.temp_tablespaces, указав отдельное дисковое пространство на самом быстром диске для временных файлов.work_mem. Если оперативной памяти на сервере достаточно, увеличение этого параметра позволит операциям сортировки и соединения таблиц платформы 1С выполняться в ОЗУ без сброса промежуточных результатов во временные файлы на диске.