Как рассчитать и оптимизировать требуемое место на диске перед обновлением базы 1С на PostgreSQL

Разберем классическую ситуацию, с которой регулярно сталкиваются администраторы и программисты. При обновлении типовой конфигурации, база данных размером около 20 гигабайт внезапно останавливает работу с ошибкой СУБД PostgreSQL: no space left on device. Свободных 7 гигабайт на диске оказывается недостаточно. Возникает закономерный вопрос руководства: существуют ли методы анализа и прогнозирования требуемого места для предстоящего обновления? Проанализируем эту проблему со всех сторон, выясним истинные причины "поедания" дискового пространства и рассмотрим эффективные решения.

Почему при реструктуризации стремительно исчезает место?

Чтобы понять, как правильно рассчитывать ресурсы сервера, посмотрим на внутреннюю механику взаимодействия платформы 1С и СУБД PostgreSQL. Нехватка места редко связана с добавлением самих новых данных (кода или форм), чаще всего дисковое пространство съедают служебные и временные операции.

1. Создание полных копий таблиц. При классическом механизме реструктуризации базы данных, когда изменяются метаданные (например, добавляется новый реквизит в массивный регистр или документ), платформа не просто добавляет колонку. Она создает полную физическую копию изменяемой таблицы. Данные переливаются из старой таблицы в новую, после чего старая удаляется. Если самая большая таблица вашей базы весит 5 гигабайт, вам потребуется как минимум еще 5 гигабайт свободного места только под ее временный дубликат в момент выполнения запроса.
2. Генерация журналов транзакций (WAL). База данных PostgreSQL фиксирует все массовые операции копирования и перестроения индексов в специальных журналах — Write-Ahead Log. При масштабных изменениях структуры объем этих файлов может исчисляться гигабайтами. Если параметры сервера, такие как max_wal_size, допускают хранение большого объема логов между контрольными точками, место на диске испарится очень быстро. Особенно опасен включенный параметр archive_mode: если процесс-архиватор не успевает переносить логи в резервное хранилище, они будут бесконечно накапливаться в рабочем каталоге базы.
3. Временные файлы при сортировке. Во время реструктуризации платформе необходимо перестраивать индексы. Если выделенной оперативной памяти для сервисных операций (параметр maintenance_work_mem) не хватает, СУБД начинает сбрасывать промежуточные данные на диск во временные файлы, создавая дополнительную неконтролируемую нагрузку на дисковую подсистему.

Методика предварительного анализа требуемого места

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

1. Выполните сравнение конфигураций (основной и конфигурации поставщика) перед обновлением. Ваша задача — определить самые "тяжелые" объекты конфигурации (регистры накопления, регистры сведений, объемные документы), структура которых претерпит изменения.
2. Используя консоль администрирования PostgreSQL, выполните запросы для определения физического объема таблиц этих объектов, а также размера их индексов. Дополнительно оцените объем таблицы Config.
3. Рассчитайте необходимый запас по следующей формуле: возьмите размер самой большой изменяемой таблицы и умножьте его на два (а для надежности — на три). Прибавьте к этому значению ожидаемый пиковый размер логов WAL (ограниченный вашим лимитом max_wal_size) и добавьте резерв под временные файлы.

Важно помнить: если модель восстановления базы данных не простая, а полная, требования к месту пропорционально возрастают. В критических ситуациях настоятельно рекомендуем временно отключать архивирование логов на период обновления конфигурации.

Как кардинально снизить требования к дисковому пространству

Разберем современный подход, который позволяет избежать проблем с нехваткой места. Начиная с версии платформы 8.3.11, разработчикам доступен механизм оптимизированной реструктуризации базы данных (V2). Проанализируем его преимущества.

В отличие от устаревшего подхода с полным копированием таблиц, новый алгоритм старается вносить изменения "по месту", используя нативные SQL-команды, такие как ALTER TABLE. Это позволяет не только ускорить процесс реструктуризации в несколько раз, но и свести к минимуму потребление резервного дискового пространства. Для того чтобы задействовать этот функционал, убедитесь, что на сервере 1С установлена Java, а затем активируйте режим через конфигурационный файл conf.cfg, добавив параметр UpdateDBCfg.

Мониторинг свободного места средствами 1С

Если вы хотите контролировать процесс и понимать, в какой именно момент исчезает место, воспользуемся программными средствами самой платформы. Рассмотрим скрипт, который можно запускать в фоновом режиме или в виде отдельной обработки для мониторинга локальных логических дисков сервера под управлением Windows.

Для реализации этой задачи мы используем COM-объект Scripting.FileSystemObject, который обращается к файловой системе операционной системы. Разберем код подробно:

FSO = Новый COMОбъект("Scripting.FileSystemObject");
Для каждого ТекДиск Из FSO.Drives Цикл
    Если ТекДиск.DriveType = 2 Тогда
        СвободныйОбъем = Окр(FSO.GetDrive(ТекДиск.DriveLetter).FreeSpace / 1048576, 1);
        Сообщить("Диск " + ТекДиск.DriveLetter + " свободно " + СвободныйОбъем + " Мб.");    
    КонецЕсли;    
КонецЦикла;

Посмотрим на условие DriveType = 2. Оно гарантирует, что мы опрашиваем только жесткие диски, игнорируя съемные носители, сетевые диски и CD-ROM. Метод FreeSpace возвращает значение в байтах, поэтому мы делим его на 1048576 для конвертации в более удобные мегабайты.

Подведем итог. Экономия на дисковом пространстве для серверов баз данных — плохая практика. Размер свободного места должен как минимум в 2-3 раза превышать размер самой базы данных. Однако, применяя оптимизированную реструктуризацию, анализируя структуру метаданных перед обновлением и контролируя параметры СУБД, вы сможете проводить обновления безопасно и предсказуемо даже в условиях ограниченных ресурсов.