← На главную

При выполнении процедуры «Тестирование и исправление» (ТиИ) базы данных 1С на сервере PostgreSQL системные администраторы часто сталкиваются с существенными задержками ввода-вывода (High I/O Await) и аномально долгим выполнением регламента — процесс может затягиваться на сутки и более. Разберем основные причины медленной работы, проанализируем метрики производительности и рассмотрим практические способы решения этой проблемы.

Причины медленного выполнения регламентных процедур

Проанализируем, почему штатный механизм 1С может выполнять тестирование в течение десятков часов:

1. Однопоточность обработки: Регламент «Тестирование и исправление» выполняется платформой 1С в один поток в рамках одной сессии СУБД. Наличие множества ядер процессора не дает линейного ускорения — вся нагрузка ложится на одно ядро процессора и один процесс PostgreSQL.
2. Избыточность одновременных опций: Включение всех галочек (реиндексация, пересчет итогов, проверка ссылочной и логической целостности с созданием объектов) приводит к огромному объему случайного ввода-вывода (Random I/O) и активному генерированию транзакционных логов WAL.
3. Узкие места виртуализации (KVM/QEMU): Если база данных развернута в виртуальной машине (например, под управлением CentOS на гипервизоре KVM), дисковая подсистема гипервизора может стать главным ограничителем производительности. Высокие показатели задержки записи и чтения (r_await, w_await) прямо указывают на проблемы с дисками.

Перенос регламента на физический сервер (Bare Metal)

Одним из наиболее быстрых решений при высокой задержке виртуального диска является проведение обслуживания на физическом сервере без накладных расходов гипервизора. Рассмотрим этот алгоритм по шагам:

1. Выясним состояние СУБД: процедура снятия дампа через pg_dump не требует монопольного доступа к базе данных. Нам не нужно ждать завершения долгого тестирования в виртуальной машине — создание копии можно запустить параллельно.
2. Развернем полученный дамп базы на отдельном физическом сервере с быстрым локальным накопителем (например, серверным SSD или NVMe).
3. Запустим процедуру «Тестирование и исправление» на физической машине. Отсутствие эмуляции ввода-вывода гипервизора и высокая скорость диска позволяют сократить время выполнения с нескольких суток до 15–30 минут.
4. После успешного проведения исправлений перенесем проверенную базу данных обратно в продуктивную среду.

Оптимизация параметров виртуализации (KVM)

Если обслуживание базы данных необходимо выполнять непосредственно внутри виртуальной машины, проанализируем настройки дисковых контроллеров и режимов кэширования гипервизора KVM:

1. Интерфейс диска: Не используйте устаревшие эмулируемые шины ide или sata. Оптимальным выбором для СУБД PostgreSQL на Linux является контроллер virtio-scsi с включенной функцией iothread (вынос обработки операций ввода-вывода в отдельный поток).
2. Прямой доступ к дискам: Для достижения максимальной скорости подключайте виртуальные диски как блочные устройства (LVM, RAW-разделы) или выделяйте физический SSD напрямую под виртуальную машину, избегая использования формата файлов образов qcow2.
3. Режим кэширования: На уровне гипервизора для диска с базой данных установите параметр cache='none' (чтобы избежать двойного кэширования в хостовой и гостевой ОС) и режим асинхронного ввода-вывода io='native'.

Настройка PostgreSQL для регламентных процедур

Тяжелые операции обслуживания требовательны к оперативной памяти и интенсивной записи WAL-логов. Посмотрим, какие параметры конфигурации postgresql.conf помогут ускорить процедуру:

1. Увеличение памяти для обслуживания: Установите параметр maintenance_work_mem в значение от 1 ГБ до 2 ГБ (при наличии 16 ГБ ОЗУ на сервере). Это значительно ускорит операции переиндексации и сбора статистики.
2. Временное отключение синхронной фиксации: На время проведения обслуживания или при проверке на технологическом контуре можно установить synchronous_commit = off. Это избавит СУБД от постоянного ожидания сброса WAL на диск.
3. Сглаживание контрольных точек: Установка checkpoint_completion_target = 0.9 предотвращает резкие пиковые нагрузки на дисковую систему во время сброса грязных страниц из буферного кэша.

Поэтапное выполнение проверок

Вместо одновременного запуска всех процедур рекомендуем разделять регламент на несколько независимых шагов:

1. Запустите первым шагом «Реиндексацию таблиц» и «Пересчет итогов». Реиндексацию также можно выполнить непосредственно средствами СУБД через команду REINDEX DATABASE.
2. Вторым шагом выполните «Проверку логической целостности» и «Проверку ссылочной целостности».
3. Для регулярного поддержания порядка в структуре таблицы PostgreSQL рекомендуем регулярно выполнять служебную процедуру очистки и обновления статистики VACUUM ANALYZE.