← На главную

При организации совместной разработки в среде 1С перед программистами и системными администраторами встает задача правильного планирования дисковых ресурсов под хранилище конфигурации. Недостаток дискового пространства или некорректная оценка его роста со временем могут привести к аварийной остановке работы команды разработки, ошибкам блокировок и повреждению структуры данных. Разберем подробно, из чего складывается объем хранилища, как рассчитать необходимую квоту на сервере и как преодолеть платформенные ограничения.

Факторы роста и ориентировочный расчет объема

Хранилище конфигурации физически представляет собой специализированную файловую информационную базу (файл с именем 1Cv8ddb.1CD). При первоначальном создании и захвате объектов оно занимает объем, сопоставимый с файлом конфигурации (в среднем от 100 до 300 МБ для типовых решений вроде 1С:Зарплата и Управление Персоналом). Однако динамика его роста зависит от нескольких ключевых факторов:

1. Частота помещения изменений: каждое сохранение версии создает дельту изменений, а при модификации тяжелых объектов конфигурации платформе требуется сохранять их полные снимки.
2. Типовые обновления: при накатывании масштабных релизов поставщика обновляется огромное число объектов метаданных одновременно. Одно крупное обновление может увеличить размер хранилища сразу на несколько сотен мегабайт.
3. Количество разработчиков: активная параллельная работа нескольких специалистов приводит к частому созданию новых версий конфигурации.

Проанализируем практический расчет для конфигурации уровня ЗУП с низкой и средней интенсивностью правок (регулярные обновления и локальные доработки):

1. Минимальный объем: 5–8 ГБ. Этого объема гарантированно хватает на 1–2 года умеренной разработки.
2. Рекомендуемый объем с запасом на 3 года: от 20 до 50 ГБ. Выделение такого дискового пространства полностью устраняет риск внезапной нехватки места на сервере и оставляет запас под технологические нужды (резервные копии, временные файлы и дампы).

Технические ограничения файловой СУБД и размер страницы

Выясним причину распространенной проблемы, с которой сталкиваются команды разработчиков: даже при наличии свободного места на физическом диске хранилище внезапно начинает выдавать системные ошибки при помещении объектов. Это связано с внутренним форматом базы 1CD.

По умолчанию файловая СУБД 1С использует размер страницы 4 КБ. При таких параметрах максимальный размер одной внутренней таблицы базы данных не может превышать 4 ГБ. В хранилище конфигурации вся история версий накапливается именно в таблицах версий и данных конфигурации. В результате база объемом около 4–8 ГБ часто упирается в архитектурный лимит платформы.

Чтобы снять это ограничение и не создавать хранилище заново, выполним конвертацию базы хранилища с увеличением размера страницы. Рассмотрим этот процесс по шагам:

1. Останавливаем службу сервера хранилища или отключаем доступ всех пользователей к сетевой папке.
2. Создаем резервную копию файла 1Cv8ddb.1CD.
3. Запускаем утилиту командной строки cnvdbfl.exe (расположена в каталоге bin установленной платформы 1С) с указанием нового размера страницы (доступны значения 8k, 16k, 32k, 64k). Например, использование страницы 64 КБ отодвигает предел размера таблицы до десятков гигабайт.
4. Проверяем целостность сконвертированного файла утилитой chdbfl.exe перед возвратом в эксплуатацию.

Штатное обслуживание: сокращение истории и сжатие

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

1. Сокращение истории: в конфигураторе перейдем в меню Конфигурация — Хранилище конфигурации — Администрирование хранилища. На вкладке управления версиями доступна команда Сократить историю хранилища до версии. Выбираем стабильную версию (например, номер полугодовой или годовой давности). Все промежуточные шаги до указанной версии будут удалены.
2. Оптимизация и сжатие: после физической пометки записей на удаление размер файла 1Cv8ddb.1CD автоматически не уменьшается. Чтобы вернуть свободное место файловой системе, необходимо выполнить сжатие хранилища через соответствующую команду в панели администрирования.

Организация доступа: сетевая папка против сервера хранилища

Размещение файла хранилища в общей папке через сетевой протокол SMB допустимо только при индивидуальной работе. В условиях команды даже из 2–3 человек такой подход несет высокие риски разрушения базы из-за нестабильности сети или внезапного разрыва соединения во время транзакции записи.

Рекомендуется разворачивать специализированный сервер хранилища конфигурации — crserver.exe, либо публиковать хранилище на веб-сервере по протоколам HTTP/HTTPS. Сервер хранилища изолирует дисковые операции, выполняет их локально и существенно снижает вероятность логического повреждения структуры файла базы данных.

Потребление места на компьютерах разработчиков

При планировании инфраструктуры важно помнить, что дисковое пространство расходуется не только на центральном сервере, но и на локальных машинах программистов. Платформа 1С кэширует версии и объекты хранилища в каталоге профиля пользователя AppData (для Windows).

Каждое открытие старой версии конфигурации или частое сравнение и объединение формируют временные копии конфигурации на диске разработчика. При активной работе с конфигурацией 1С:Зарплата и Управление Персоналом локальный кэш версий может разрастаться до 10–20 ГБ на каждого разработчика. Рекомендуется регулярно очищать локальный кэш хранилища и выделять под системный диск разработчика достаточный объем памяти.

Современные альтернативы для контроля версий

Если проект активно развивается и объем изменений велик, замедлить рост хранилища или вовсе отказаться от его ограничений позволяют следующие архитектурные подходы:

1. Использование расширений (cfe): вынесение локальных правок, новых отчетов и печатных форм в расширения позволяет оставить основную типовую конфигурацию неизменной, благодаря чему основное хранилище практически не разрастается.
2. Переход на Git: версионирование конфигурации в виде исходных файлов (XML/BSL) с использованием 1C:Enterprise Development Tools (EDT) или внешних утилит выгрузки. Git эффективно сжимает текстовые файлы исходного кода и не подвержен ограничениям на размер единичной таблицы СУБД.