Как работает серверный вариант 1С

Серверный вариант 1С — это трёхуровневая архитектура, в которой данные хранятся не в файле на диске, а в базе данных под управлением СУБД, а между пользователем и базой работает промежуточный слой — кластер серверов 1С:Предприятия. Пользователь запускает тонкий или толстый клиент, клиент подключается к кластеру, кластер выполняет запросы к СУБД и возвращает результат. Такая схема снимает главные ограничения файлового режима: блокировки всей таблицы, деградацию при росте базы и риск повреждения файла при сбое сети.

Практический смысл перехода на серверный вариант появляется, когда одновременно работают больше 5–10 пользователей, база превышает несколько гигабайт или требуется регламентное обслуживание без остановки работы. В файловом режиме каждый пользователь напрямую читает и пишет общий файл 1Cv8.1CD, и при активной работе это приводит к конфликтам блокировок и падению производительности. В серверном режиме конкуренцию за данные разрешает СУБД, которая умеет блокировать отдельные строки и обслуживать сотни соединений.

Важно понимать, что «серверный вариант» — это не одна программа, а связка из трёх компонентов: СУБД (MS SQL Server, PostgreSQL, Oracle или IBM DB2), сервер 1С:Предприятия и клиентское приложение. Каждый компонент настраивается отдельно, и проблемы производительности почти всегда лежат на стыке между ними: нехватка памяти СУБД, медленный диск под tempdb, неверные настройки кластера или тяжёлые запросы в конфигурации.

Из каких компонентов состоит серверная архитектура 1С

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

Второй уровень — кластер серверов 1С:Предприятия. Это служба (агент сервера), которая управляет рабочими процессами rphost. Именно в rphost исполняется серверный код конфигурации: проведение документов, расчёты, формирование отчётов. Кластер распределяет соединения между рабочими процессами, хранит сеансовые данные и лицензии, а также может объединять несколько физических серверов для отказоустойчивости.

Третий уровень — СУБД. Она хранит таблицы, индексы и обеспечивает транзакционность: либо вся операция проведения документа завершается целиком, либо откатывается полностью. Платформа 1С не работает с файлами данных напрямую — все чтения и записи идут через SQL-запросы, которые генерирует сервер 1С. Поэтому здоровье СУБД (память, диски, статистика, индексы) напрямую определяет скорость работы пользователей.

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

Когда бухгалтер нажимает «Провести» в документе, клиент отправляет вызов на сервер 1С по протоколу TCP (по умолчанию кластер слушает порты 1540–1541, рабочие процессы — диапазон 1560–1591). Менеджер кластера выбирает рабочий процесс rphost, в котором открыт сеанс пользователя, и передаёт ему вызов. Rphost выполняет код обработчика проведения, формирует SQL-запросы к СУБД, получает данные, обрабатывает их и возвращает результат клиенту.

На этом пути есть три потенциальных узких места. Первое — сеть между клиентом и сервером: для тонкого клиента трафик невелик, но толстый клиент при работе через медленный канал заметно тормозит. Второе — сам rphost: тяжёлый отчёт может загрузить одно ядро процессора и съесть гигабайты памяти одного процесса. Третье — СУБД: неоптимальный запрос без подходящего индекса заставляет сервер баз данных перечитывать миллионы строк.

Фоновые и регламентные задания выполняются тем же кластером, но без участия клиента: планировщик внутри кластера запускает задание в отдельном сеансе на рабочем процессе. Поэтому тяжёлые ночные операции (пересчёт итогов, обмены данными) конкурируют за ресурсы с пользователями, если их не ограничить по времени или не вынести на отдельный рабочий сервер кластера.

Чем серверный вариант отличается от файлового

Различия между режимами принципиальны, а не косметические. В файловом варианте платформа сама управляет блокировками на уровне таблиц целиком, в серверном — работает управляемый режим блокировок на уровне записей, который реализует СУБД. Это главный источник выигрыша в многопользовательской среде.

Обратите внимание на последнюю строку: в серверном варианте резервные копии делаются средствами СУБД без остановки работы, и это правильный способ. Копирование файлов базы данных «как папки» или снапшоты виртуальной машины без согласования с СУБД могут дать несогласованную копию, из которой база не восстановится.

Когда какой вариант выбирать

Файловый вариант

Подходит для 1–5 пользователей, небольшой базы и простой инфраструктуры. Ограничение: табличные блокировки и риск повреждения файла при сбоях сети.

Серверный на одном сервере

СУБД и сервер 1С на одной машине. Подходит для 10–50 пользователей при достаточном объёме RAM. Ограничение: единая точка отказа.

Разнесённый серверный вариант

СУБД и кластер 1С на разных серверах, возможно несколько рабочих серверов в кластере. Для 50+ пользователей и требований к отказоустойчивости. Ограничение: сложнее администрирование и выше требования к сети между серверами.

Как развернуть серверный вариант: порядок действий

Развёртывание начинается с выбора СУБД. Для лицензионно чистого и бюджетного решения чаще всего берут PostgreSQL со сборкой, адаптированной под 1С; для крупных внедрений с имеющейся инфраструктурой Microsoft — MS SQL Server. Требования к версиям СУБД зависят от версии платформы 1С, поэтому перед установкой сверяйтесь с системными требованиями конкретного релиза платформы.

Далее устанавливается сервер 1С:Предприятия той же версии платформы, что и клиенты (или с совместимым набором версий, если используется несколько). После установки создаётся кластер по умолчанию, и в консоли администрирования серверов регистрируется новая информационная база: указывается тип СУБД, имя сервера баз данных, имя базы и учётная запись с правами на создание базы. Платформа сама создаст базу и развернёт структуру при загрузке конфигурации из dt-файла или при создании пустой базы.

1. 1
   Установите и настройте СУБД: выделите память, разместите данные и журнал транзакций на быстрых дисках
2. 2
   Установите сервер 1С:Предприятия нужной версии платформы и запустите службу агента сервера
3. 3
   Откройте консоль администрирования серверов, зарегистрируйте кластер
4. 4
   Создайте информационную базу: укажите тип СУБД, сервер БД, имя базы и учётные данные
5. 5
   Загрузите конфигурацию из dt-файла или выполните конвертацию из файлового варианта через выгрузку/загрузку
6. 6
   Настройте регламентные операции СУБД: бэкапы, обновление статистики, реиндексацию
7. 7
   Проверьте подключение клиентом и работу типовых операций под нагрузкой

Переход с файлового варианта делается только через выгрузку информационной базы в файл .dt (Конфигуратор → Администрирование → Выгрузить информационную базу) и последующую загрузку в серверную базу. Просто «положить файл 1Cv8.1CD на SQL Server» нельзя — форматы хранения несовместимы.

Требования к оборудованию и настройка производительности

Главный ресурс для серверного 1С — оперативная память и быстрые диски, а не количество ядер процессора. СУБД должна держать активную часть базы в буферном кэше: если рабочий набор данных не помещается в память, каждый запрос упирается в диск. Практическое правило: суммарной памяти сервера должно хватать на буферы СУБД плюс по несколько гигабайт на каждый рабочий процесс rphost — тяжёлые отчёты легко потребляют 2–4 ГБ на процесс.

Диски критичны для журнала транзакций СУБД: он пишется последовательно и синхронно, поэтому медленный диск под журнал тормозит все операции записи. Размещайте журнал и данные на разных физических устройствах, используйте SSD. Для PostgreSQL отдельно настраивают shared_buffers, work_mem и effective_cache_size — значения по умолчанию рассчитаны на слабое оборудование и для 1С непригодны.

В кластере 1С настраивают количество рабочих процессов на сервер и лимит памяти на процесс. Один rphost исполняет код в один поток, поэтому несколько процессов позволяют задействовать несколько ядер и изолируют сбои: падение одного процесса не роняет все сеансы. Свойство «Допустимый объём памяти» для рабочих процессов защищает сервер от утечек: процесс, превысивший лимит, перезапускается после завершения вызовов.

Контрольные точки

Как проверить результат настройки

Использование памяти сервером

Норма

Занято 70–85% RAM, нет активного свопинга

Тревожный признак

Постоянный своп, ОС выгружает страницы на диск

Время отклика типовых операций

Норма

Проведение документа — секунды, отчёты открываются предсказуемо

Тревожный признак

Резкие скачки времени отклика при росте числа пользователей

Процессы rphost

Норма

Несколько процессов, память распределена равномерно

Тревожный признак

Один процесс съел всю память и растёт

Блокировки в СУБД

Норма

Кратковременные ожидания, нет длинных цепочек

Тревожный признак

Взаимоблокировки и очереди ожидающих запросов в часы пик

Типичные ошибки и ограничения серверного варианта

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

Вторая группа ошибок — пренебрежение обслуживанием СУБД. Без регулярного обновления статистики оптимизатор запросов начинает строить плохие планы, без реиндексации растёт фрагментация, без контроля журнала транзакций в модели полного восстановления диск переполняется и база встаёт. Эти регламентные операции — обязательная часть эксплуатации, а не опция.

Третья распространённая проблема — размещение СУБД и сервера 1С на одной машине с недостаточным объёмом памяти: оба компонента начинают конкурировать за RAM, ОС уходит в своп, и производительность деградирует катастрофически. Если сервер один, явно ограничьте память СУБД, оставив запас кластеру 1С и операционной системе.

Как администрировать и контролировать работающую систему

Ежедневный контроль сводится к трём вещам: свободное место на дисках СУБД, успешность ночных бэкапов и отсутствие аномалий в журнале регистрации 1С и журналах СУБД. Журнал регистрации в серверном варианте хранится на сервере 1С и доступен из конфигуратора; по нему отслеживают ошибки фоновых заданий, отказы соединений и действия пользователей.

Для диагностики производительности используйте технологический журнал платформы (логирование событий DBMSSQL, EXCP, CALL) и счётчики СУБД: длительные запросы, ожидания блокировок, попадания в буферный кэш. В MS SQL Server удобны динамические представления sys.dm_exec_requests и отчёты по ожиданиям; в PostgreSQL — pg_stat_activity и pg_stat_statements. Не включайте полный техножурнал на постоянной основе: подробное логирование само по себе заметно нагружает диск.

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

Частые вопросы о серверном варианте 1С

Можно ли использовать бесплатную СУБД вместо MS SQL Server?

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

Сколько пользователей выдержит серверный вариант?

Точного числа нет — предел зависит от конфигурации, характера нагрузки и оборудования. Один современный сервер с достаточным объёмом RAM и SSD обычно комфортно обслуживает десятки одновременных пользователей; при больших нагрузках кластер масштабируют добавлением рабочих серверов. Практический критерий — время отклика типовых операций и загрузка ресурсов в часы пик, а не номинальное число лицензий.

Нужно ли менять конфигурацию при переходе с файлового варианта?

Типовые конфигурации на управляемых формах обычно работают без доработок — конвертация делается выгрузкой и загрузкой dt. Но самописные и сильно доработанные решения нужно тестировать: на СУБД иначе работают запросы и блокировки, и код, приемлемый для файлового режима, может давать конфликты блокировок или медленные запросы. Тестовый прогон на копии обязателен.

Что делать, если база стала тормозить после перехода на сервер?

Начните с трёх проверок: достаточно ли памяти выделено СУБД и нет ли свопинга, обновляется ли статистика и индексы, нет ли длинных запросов и блокировок в мониторе СУБД. Чаще всего причина в параметрах СУБД «по умолчанию» или в конкретных неоптимальных запросах, которые находят через технологический журнал по событиям длительных обращений к базе.

Можно ли сделать резервную копию, не останавливая работу пользователей?

Да, это одно из главных преимуществ серверного варианта. СУБД выполняет резервное копирование «на горячую», без завершения сеансов. Копирование файла 1Cv8.1CD, наоборот, требует отсутствия активных подключений. Настройте расписание полных бэкапов и, при полной модели восстановления, регулярные бэкапы журнала транзакций.

Чем веб-клиент отличается от тонкого в серверном варианте?

Оба выполняют логику на сервере, но веб-клиент работает в браузере и подключается через веб-сервер (IIS или Apache), на котором публикуется база. Это удобно для удалённых сотрудников без установки платформы, но требует настройки веб-сервера и защищённого канала. Тонкий клиент подключается к кластеру напрямую и обычно отзывчивее в локальной сети.