Файловый режим против клиент-серверного: когда 1С летает, а когда тормозит

При одном-трёх пользователях файловая 1С на локальном SSD обычно быстрее серверной на SQL: короткие операции идут без сетевых задержек и без межпроцессного обмена. Как только в базе одновременно работают пять-десять человек, проводят документы и строят тяжёлые отчёты, выигрывает клиент-серверная версия на MS SQL или PostgreSQL. Там нет блокировок целых таблиц, запросы выполняет оптимизатор СУБД, а фоновые задания не мешают людям.

Ответ «что быстрее» поэтому зависит не от платформы 1С, а от нагрузки: числа пользователей, объёма базы, тяжести отчётов и того, где лежит файл базы.

Как устроены файловый и SQL-вариант 1С изнутри

В файловом варианте вся база — один файл 1Cv8.1CD в каталоге информационной базы. Отдельного сервера нет: движок файловой СУБД работает прямо внутри процесса клиента (1cv8c.exe для тонкого клиента , 1cv8.exe для толстого) или внутри веб-сервера, если база опубликована.

В клиент-серверном варианте работают три звена:

• 🖥 Клиент — тонкий, толстый или веб. Он только показывает формы и отправляет вызовы.
• ⚙️ Кластер серверов 1С — агент ragent (порт 1540), менеджер кластера rmngr (1541) и рабочие процессы rphost (диапазон портов задаётся в свойствах рабочего сервера, по умолчанию 1560–1591). Здесь выполняется серверный код конфигурации.
• 🗄 СУБД — MS SQL Server, PostgreSQL, IBM Db2 или Oracle Database. Данные хранятся в таблицах СУБД, запросы 1С транслируются в SQL.

Из таблицы видно главное: «SQL-версия» — это не та же база в другом формате. Это другая архитектура, где тяжёлую работу делает сервер, а не компьютер бухгалтера.

Один-три пользователя: почему файловая база часто быстрее

На маленькой нагрузке у файловой базы преимущество — короткий путь данных. Клиент читает страницы файла с локального диска и сразу их обрабатывает. В клиент-серверном варианте каждый серверный вызов проходит клиент → рабочий процесс → СУБД и обратно. Каждое звено добавляет миллисекунды.

Для одной операции это незаметно. Но открытие формы документа с десятком реквизитов — это множество мелких обращений. На них файловая база отвечает быстрее, особенно если файл лежит на NVMe-диске той же машины.

Типичная картина у ИП или небольшой фирмы с одним бухгалтером:

• 📄 открытие списков и форм — файловая быстрее или наравне;
• ✅ проведение одного документа — разница в доли секунды;
• 📊 оборотно-сальдовая ведомость за месяц — наравне;
• 🔄 закрытие месяца на базе в несколько гигабайт — сервер уже начинает выигрывать.

Сильнее всего на скорость файловой базы влияет место хранения файла:

1. Локальный диск этой же машины — лучший вариант.
2. Терминальный сервер (RDP) с базой на его собственном диске — пользователи работают удалённо, а движок читает файл локально. Для 5–15 человек это частый компромисс.
3. Публикация на веб-сервере (Apache или IIS) — движок работает в процессе веб-сервера рядом с файлом, клиенты ходят по HTTP.
4. Сетевая папка (SMB) — самый медленный путь. Каждое чтение страницы идёт по сети, а через VPN база становится практически непригодной.

Многопользовательская работа: где файловая 1С начинает тормозить

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

Пока людей двое, ожидания не видно. Когда десять человек одновременно проводят реализации и поступления, очередь становится заметной: «песочные часы» по несколько секунд, а при долгих транзакциях — ошибки блокировки.

В клиент-серверном варианте с управляемым режимом блокировок 1С блокирует не таблицу, а конкретные записи. Два менеджера, продающие разные товары с разных складов, друг другу не мешают. Ждут только те, кто пишет в одни и те же строки остатков.

Что ещё меняется при росте числа пользователей:

• 🔒 Регламентные задания. В файловой базе их выполняет клиентский сеанс одного из пользователей, и этот пользователь чувствует замедление. В кластере они идут отдельно.
• 🌐 Сеть. Файловые клиенты через SMB тянут страницы файла каждый сам. Серверные клиенты передают только результат и данные форм.
• 🧠 Память и процессор. Тяжёлые вычисления в файловом варианте идут на компьютере пользователя. На слабых ноутбуках это заметно сильнее, чем на сервере.

На практике граница проходит в районе пяти-десяти одновременно активных пользователей. Это не жёсткий предел платформы, а точка, где жалобы на скорость появляются почти всегда. Десять человек, которые раз в час смотрят справочники, файловая база выдержит. Пять человек, которые весь день проводят документы, — уже с трудом.

Тяжёлые отчёты и закрытие месяца: скорость запросов в двух режимах

На больших выборках преимущество переходит к SQL-серверу, и разрыв бывает кратным. Причины:

1. Оптимизатор запросов. MS SQL и PostgreSQL выбирают план выполнения по статистике: какой индекс использовать, в каком порядке соединять таблицы. Файловый движок устроен проще.
2. Параллелизм. СУБД может выполнять один тяжёлый запрос на нескольких ядрах. Файловый движок такой возможности для одного запроса не даёт.
3. Кэширование. Сервер СУБД держит горячие данные в оперативной памяти, общей для всех пользователей. Файловые клиенты кэшируют каждый у себя.
4. Временные таблицы. Отчёты СКД и обработки закрытия месяца активно создают временные таблицы. В СУБД под это есть отдельная оптимизированная подсистема.

Где разница ощущается сильнее всего:

Ещё один нюанс: базу на SQL-сервере нужно обслуживать. Без регулярного обновления статистики и перестроения индексов (план обслуживания в MS SQL, VACUUM и ANALYZE в PostgreSQL) она со временем замедляется, и сервер теряет своё преимущество.

Надёжность при сбоях: какой вариант быстрее восстанавливается

Скорость важна не только в работе, но и при аварии. Здесь разница между вариантами ещё заметнее.

Файловая база уязвима к обрыву записи. Если во время транзакции пропало питание, отвалилась сеть до сетевой папки или «завис» компьютер пользователя, файл 1Cv8.1CD может оказаться повреждён. Особенно часто это бывает при работе через SMB.

Для восстановления используют утилиту chdbfl.exe из каталога bin платформы (тестирование и исправление файловой базы) или режим «Тестирование и исправление» в конфигураторе. Перед запуском любой из них скопируйте файл базы целиком — исправление может удалить повреждённые данные без возможности отката. Обе процедуры требуют монопольного доступа, поэтому всем пользователям придётся выйти из базы.

SQL-база защищена журналом транзакций СУБД. Незавершённая транзакция при сбое откатывается, и база остаётся согласованной. Дополнительно:

• 💾 резервную копию средствами СУБД делают без отключения пользователей;
• ⏪ в MS SQL с полной моделью восстановления можно вернуть базу на момент до ошибки, например за пять минут до массового удаления документов;
• 📦 выгрузка .dt остаётся дополнительным способом, но для ежедневных копий большой базы она неудобна.

Если база — это вся бухгалтерия компании за годы, надёжность сама по себе может оказаться весомее разницы в скорости.

Как измерить скорость на своей базе перед выбором

Чтобы не решать «на глаз», замерьте конкретные операции, на которые жалуются пользователи.

1. Выберите 3–5 типичных операций: проведение реализации на 50 строк, формирование ОСВ за год, закрытие месяца, открытие списка документов.
2. Замерьте их в файловой базе секундомером или встроенным замером производительности. В конфигураторе запустите отладку и включите Отладка → Замер производительности — он покажет, какие строки кода занимают больше всего времени.
3. Разверните копию базы на тестовом сервере. Для пробы подойдёт PostgreSQL в сборке для 1С и сервер 1С на той же машине.
4. Повторите замеры в одном и том же порядке, после «прогрева» (первый запуск всегда медленнее из-за пустого кэша).
5. Проверьте одновременную работу: попросите 3–4 сотрудников одновременно проводить документы и посмотрите, растёт ли время ожидания.

Для оценки «железа» многие администраторы используют сторонний синтетический тест Гилёва. Он показывает условную производительность связки процессор — диск — СУБД, но не заменяет замеров на вашей конфигурации.

Когда переходить на SQL-сервер и как перенести базу

Сигналы, что файловая база упёрлась в свой потолок:

• ⏳ пользователи регулярно ждут, пока коллега проведёт документ;
• ❌ появляются ошибки блокировки данных при одновременной работе;
• 📈 закрытие месяца идёт дольше получаса и его приходится запускать вечером;
• 🌍 нужен доступ из филиалов, а сетевая папка через VPN не работает ;
• 💥 файл базы уже повреждался и восстанавливался.

Перенос делается через выгрузку и загрузку информационной базы:

1. Предупредите пользователей и выберите время: на выгрузку нужен монопольный доступ, все сеансы будут завершены.
2. Откройте файловую базу в конфигураторе и выполните Администрирование → Выгрузить информационную базу — получите файл .dt.
3. Создайте новую базу на сервере: в окне запуска 1С нажмите «Добавить», выберите создание новой базы и вариант «На сервере 1С:Предприятия». Укажите кластер, имя базы, тип СУБД, сервер баз данных и учётную запись СУБД. Можно создать базу и через консоль администрирования кластера.
4. Откройте новую пустую базу в конфигураторе и выполните Администрирование → Загрузить информационную базу, выбрав файл .dt.
5. Проверьте: зайдите под пользователем, сформируйте ОСВ и сверьте итоги с файловой базой.
6. Пропишите новую базу у пользователей, а старую файловую переименуйте, чтобы в неё не продолжали вносить данные.

По затратам: понадобится лицензия на сервер 1С:Предприятия (ориентировочно порядка сотни тысяч рублей, точную цену и вид лицензии уточняйте у партнёра), машина под сервер и, при MS SQL, его лицензия. PostgreSQL в сборке для 1С бесплатен, поэтому малый бизнес часто начинает с него. Клиентские лицензии остаются прежними.

Частые вопросы