← На главную

Работа с файловой базой 1С (формат .1CD) на определенном этапе роста предприятия неизбежно приводит к деградации производительности. Когда объем базы достигает внушительных размеров (например, 17 ГБ или 30 ГБ), а количество пользователей превышает 5 человек, стандартные методы оптимизации перестают помогать. В этой статье мы подробно разберем, почему сервер начинает «задыхаться», как оперативная память заполняется процессами 1cv8.exe и какие шаги необходимо предпринять для стабилизации системы.

Проанализируем причины разрастания оперативной памяти в RDP-сессиях

В рассматриваемой ситуации пользователи работают через Terminal Server (RDP). Это важный нюанс. Разберем по шагам, что происходит в памяти сервера при каждом подключении:

1. Для каждого пользователя операционная система запускает отдельный экземпляр приложения 1cv8.exe.
2. Каждый такой процесс является полноценным «толстым» или «тонким» клиентом. В файловом режиме именно этот процесс берет на себя всю работу по обработке данных, выполнению запросов и компиляции программного кода.
3. Современные типовые конфигурации (например, Бухгалтерия предприятия 3.0 или ЗУП 3.1) крайне требовательны к ресурсам. Один запущенный процесс 1С может потреблять от 500 МБ до 1.5 ГБ оперативной памяти даже в состоянии покоя.
4. При работе с базой в 17 ГБ процессы начинают кэшировать огромные объемы данных. Если пользователи формируют тяжелые отчеты или выполняют групповое проведение документов, память не всегда возвращается операционной системе немедленно после завершения операции. Это явление часто называют «утечкой памяти», хотя зачастую это просто специфика работы менеджера памяти 1С.

Результат: 5-10 пользователей в RDP-сессии легко могут занять 12-16 ГБ оперативной памяти только под нужды 1С, не считая ресурсов самой ОС и других приложений.

Выясним причину загрузки процессора на 12.5% и зависаний

Рассмотрим ситуацию, когда сервер имеет 8-ядерный процессор, но при «тормозах» общая загрузка показывает всего 12.5%. Это классический признак однопоточности файловой 1С. Математика проста: 100% мощности делится на 8 ядер, что дает 12.5% на одно ядро.

Файловая СУБД 1С не умеет распределять выполнение одной тяжелой задачи (например, расчет себестоимости) между несколькими ядрами. В итоге одно ядро загружено на 100%, а остальные простаивают. Для пользователя это выглядит как полное зависание программы. Если при этом база заблокирована на запись (об этом ниже), стоять в очереди будут все пользователи сразу.

Разберем архитектурные ограничения файлового режима

Проанализируем структуру файла .1CD. Файловая база — это фактически набор таблиц внутри одного файла. У нее есть критические лимиты:

• Ограничение на размер таблицы: Внутренняя таблица базы (например, регистр бухгалтерии) не может превышать 4 ГБ. Даже если вся база весит 17 ГБ, она может работать, пока ни одна из ее внутренних таблиц не уперлась в этот порог. Как только это произойдет, база выдаст ошибку записи.
• Механизм блокировок: В клиент-серверном варианте (SQL) СУБД умеет блокировать отдельные строки (записи). В файловом варианте при записи часто блокируется вся таблица целиком. Если один пользователь проводит документ, остальные ждут завершения транзакции на уровне файловой системы.

Вариант решения №1: Переход на клиент-серверную архитектуру (SQL)

Это единственный надежный способ решения проблемы для базы объемом 17 ГБ. Рассмотрим, как меняется схема работы:

1. Трехуровневая архитектура: Появляется промежуточное звено — Кластер серверов 1С.
2. Данные хранятся в профессиональной СУБД (MS SQL или PostgreSQL).
3. Тяжелые запросы и обработка кода переносятся с компьютеров пользователей (или их RDP-сессий) на мощный сервер 1С.
4. Клиентское приложение (тонкий клиент) становится «легким» и потребляет значительно меньше оперативной памяти.

Для небольших компаний существует бюджетное решение — «1С:Сервер мини на 5 подключений». Он позволяет использовать все преимущества SQL-версии без покупки дорогостоящей лицензии на полноценный сервер предприятия.

Вариант решения №2: Использование Веб-сервера (Apache или IIS)

Если переход на SQL пока невозможен, проанализируем работу через веб-сервер. В этом случае работа с файлом .1CD идет не от множества пользователей через RDP, а от одного процесса веб-сервера (модуля расширения 1С).

Преимущества:

• Снижается нагрузка на файловую систему, так как нет конфликтов множественного доступа к файлу от разных сессий RDP.
• Пользователи могут работать через браузер или тонкий клиент, что позволяет отказаться от части RDP-лицензий и снизить потребление RAM на сервере.

Важно: Веб-сервер не делает файловую базу многопоточной и не снимает ограничение в 4 ГБ на таблицу. Это лишь «косметическая» мера для стабилизации доступа.

Вариант решения №3: Оптимизация и свертка базы

Рассмотрим возможность уменьшения объема данных. База 17 ГБ для файлового режима — это «зона риска». Повреждение такого файла может привести к безвозвратной потере данных, так как утилита chdbfl.exe часто не справляется с объектами такого размера.

Рекомендуемые действия:

1. Проанализировать состав таблиц. Возможно, большую часть объема занимают присоединенные файлы (сканы договоров, чеки). Их лучше хранить в томах на диске, а не в самой базе.
2. Выполнить свертку информационной базы. Это процесс удаления старых документов и формирования начальных остатков на определенную дату (например, на начало года).
3. Перенести справочники и остатки в чистую новую базу. Это позволит уменьшить файл .1CD в несколько раз и значительно ускорит работу.

Технические рекомендации по настройке сервера

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

• Дисковая подсистема: База должна лежать на SSD или NVMe накопителе. Обычные HDD не обеспечивают нужного количества операций ввода-вывода (IOPS) для 5+ пользователей.
• Антивирус: Настройте исключения для файлов с расширениями .1CD, .1CL, .log, .pfl. Постоянная проверка антивирусом огромного файла базы при каждом обращении 1С — верный способ «повесить» сервер.
• Регулярное обслуживание: Обязательно выполняйте тестирование и исправление (ТиИ) со сжатием таблиц, чтобы удалить «пустоты» из файла базы.

Подведем итог: При достижении файловой базой размера более 10 ГБ и работе более 5 пользователей, проблемы с оперативной памятью и производительностью становятся системными. Оптимальный путь — миграция на PostgreSQL или MS SQL. Использование веб-сервера и свертка базы могут дать временную передышку, но не решают проблему архитектурных ограничений файлового формата.