Загрузка информационной базы из файла резервной копии (формат .dt) — стандартная операция для администраторов 1С. Однако при работе со связкой 1С:Предприятие + PostgreSQL на ОС Linux пользователи часто сталкиваются с крайне низкой скоростью импорта. Процесс может растягиваться на часы, а детальный анализ показывает, что практически все время уходит на выполнение операций CREATE INDEX (создание индексов).
В этой статье мы подробно разберем, почему возникает эта проблема, как правильно диагностировать узкие места в системе и какие настройки СУБД, платформы 1С и операционной системы Linux помогут ускорить загрузку базы в разы.
При загрузке файла .dt база данных создается практически с нуля. Платформа 1С последовательно создает таблицы, загружает в них «сырые» данные, а затем отправляет в СУБД команды на построение индексов. Создание индексов — это операция, критичная к скорости дискового ввода-вывода (I/O) и объему оперативной памяти.
Часто администраторы полагают, что с их дисками все в порядке, ориентируясь на простые тесты скорости. Однако при массовом импорте характер нагрузки меняется на случайную запись мелкими блоками. Давайте проанализируем реальный пример: база загружается более двух часов, процессор не загружен на 100%, очереди диска в гостевой ОС кажутся небольшими. Но при проверке со стороны хост-системы (если используется виртуализация) выясняется, что средняя длина очереди диска превышает допустимые значения (например, составляет 2.9 и выше для одного HDD).
Для диагностики дисковой активности в Linux мы рекомендуем использовать утилиту iostat. Запустим мониторинг с интервалом в 1 секунду:
iostat -x-d 1
Обратите внимание на следующие ключевые показатели:
Если диагностика подтвердила, что узким местом является диск, кардинальным решением станет переход на твердотельные накопители (SSD/NVMe). Если же замена оборудования невозможна прямо сейчас, или диски уже быстрые, но скорость все равно не устраивает, перейдем к программной оптимизации.
Поскольку загрузка .dt — это разовая техническая операция, мы можем временно перевести СУБД PostgreSQL в «агрессивный» режим работы, пожертвовав отказоустойчивостью на время импорта. После успешной загрузки базы настройки обязательно нужно вернуть к безопасным значениям.
Откройте конфигурационный файл postgresql.conf и внесите следующие изменения:
# Отключаем гарантированную запись на диск для каждой транзакции
fsync = off
synchronous_commit = off
# Разрешаем СУБД использовать больше памяти для создания индексов (CREATE INDEX)
maintenance_work_mem = 2GB # Установите от 20% до 50% свободной ОЗУ сервера
# Оптимизируем настройки журнала транзакций (WAL)
max_wal_size = 16GB
checkpoint_timeout = 30min
Что дают эти параметры?
Отключение параметров fsync и synchronous_commit заставляет PostgreSQL подтверждать транзакции сразу после записи в кэш оперативной памяти, не дожидаясь физического сохранения на медленный диск. Это снижает нагрузку на дисковую систему в несколько раз.
Параметр maintenance_work_mem напрямую отвечает за объем оперативной памяти, выделяемой под операции сортировки и построения индексов. Если памяти недостаточно, PostgreSQL начнет сбрасывать промежуточные данные во временные файлы на диске, что приведет к катастрофическому падению скорости. Увеличение этого параметра до 2–4 Гб позволяет построить большинство индексов типовых конфигураций (таких как КА или ERP) прямо в оперативной памяти.
Увеличение max_wal_size и checkpoint_timeout предотвращает частый сброс грязных страниц из буферного кэша на диск (так называемые контрольные точки или checkpoints), распределяя нагрузку более равномерно.
После внесения изменений не забудьте перезапустить службу СУБД:
systemctl restart postgresql
Важно: После завершения загрузки обязательно верните fsync = on и synchronous_commit = on, иначе при любом сбое по питанию база данных будет безвозвратно испорчена.
Если вы используете платформу «1С:Предприятие» версии 8.3.19 и выше, вам доступна функция многопоточного восстановления базы данных из файла .dt в клиент-серверном варианте.
По умолчанию конфигуратор выполняет загрузку в один поток. Чтобы задействовать всю мощность процессора и сократить время создания индексов, мы можем запустить импорт через командную строку с использованием пакетного режима конфигуратора и ключа -JobsCount:
/opt/1C/v8.3/x86_64/1cv8 DESIGNER /S "ИмяСервера\ИмяБазы" /N "Администратор" /P "Пароль" /RestoreIB "ПутьКФайлу.dt" -JobsCount 4
Параметр -JobsCount указывает платформе, во сколько потоков следует производить импорт данных и создание индексов. Оптимальное значение — количество физических ядер процессора на сервере 1С/СУБД.
Примечание: В некоторых случаях при экстремальной многопоточности на СУБД PostgreSQL могут возникать взаимоблокировки. Если в процессе загрузки вы видите ошибки блокировок блокирующего характера, попробуйте снизить количество потоков или запустить процесс с параметром -JobsCount 1.
Поведение операционной системы Linux по умолчанию часто ориентировано на энергосбережение или универсальные задачи, что мешает высоконагруженным СУБД. Выполним несколько системных настроек.
1. Отключение агрессивного использования SWAP
По умолчанию Linux начинает сбрасывать страницы памяти в раздел подкачки (SWAP), даже если свободная оперативная память еще есть. Если во время создания индексов PostgreSQL уйдет в SWAP на медленном диске, процесс зависнет. Проверим текущее значение параметра:
cat /proc/sys/vm/swappiness
Если там установлено стандартное значение 60, временно или постоянно установите его в 1 или 10:
sysctl vm.swappiness=10
Чтобы сохранить настройку после перезагрузки, добавьте строку vm.swappiness = 10 в файл /etc/sysctl.conf.
2. Опции монтирования файловой системы
Каждый раз, когда СУБД читает или записывает файлы таблиц, операционная система фиксирует время последнего обращения к файлу (атрибуты atime). Это создает лишние операции записи. Мы можем отключить это поведение, добавив параметры noatime,nodiratime в настройки монтирования диска с базой данных в файле /etc/fstab. Пример строки монтирования:
UUID=xxxx-xxxx-xxxx /var/lib/postgresql ext4 noatime,nodiratime,errors=remount-ro 0 1
Рассмотрим альтернативный сценарий. Формат .dt разработан фирмой 1С как универсальное средство переноса данных между различными СУБД (например, при миграции с MS SQL на PostgreSQL или наоборот). Это логический бэкап, который СУБД не понимает напрямую.
Если вы регулярно разворачиваете копии баз данных в пределах одной СУБД PostgreSQL (например, создаете тестовую базу из рабочей), использование .dt — крайне неэффективное решение. Вместо этого используйте нативные инструменты СУБД, такие как утилиты pg_dump и pg_restore.
Для создания резервной копии выполните на сервере команду:
pg_dump -U postgres -F c -b -v -f "/backup/work_db.backup" work_db
Для восстановления базы данных из этого бэкапа используйте параллельный режим (ключ -j), который разворачивает таблицы и создает индексы одновременно в несколько потоков силами самой СУБД, полностью минуя медленный уровень сервера приложений 1С:
pg_restore -U postgres -d test_db -j 4 -v "/backup/work_db.backup"
Использование нативных бэкапов PostgreSQL позволяет сократить время разворачивания баз данных в 5–10 раз по сравнению с загрузкой аналогичного файла .dt, снижая при этом нагрузку на диски до минимума.