Ситуация, когда в компании растет количество сотрудников, а серверная часть остается на уровне домашнего ПК, встречается довольно часто. Рассмотрим типовой случай: 30 пользователей работают в 1С через тонкие клиенты с файловыми базами, а в качестве «сервера» выступает машина с процессором i3-7100, 8 Гб оперативной памяти и обычными HDD-дисками. В такой конфигурации «жуткие лаги» — это закономерный результат. Разберем по шагам, как трансформировать эту систему в стабильно работающее решение.
Прежде чем бежать в магазин за новым железом, проанализируем, почему текущая схема не работает. Основная проблема здесь — это сочетание файлового режима и доступа через SMB (общие папки). Когда путь к базе прописан как сетевой ресурс, вся обработка данных ложится на плечи клиентского компьютера. По сети гоняются огромные объемы временных файлов и сырых данных из таблицы 1Cv8.1CD. Протокол SMB плохо справляется с блокировками при большом количестве одновременных подключений, что приводит к очередям и зависаниям.
Добавим к этому аппаратные ограничения: 8 Гб оперативной памяти недостаточно даже для самой операционной системы Windows Server с запущенными службами, а медленные HDD-диски создают огромные задержки на операциях чтения-записи. Процессор серии i3 имеет низкую многопоточность и не предназначен для обслуживания 30 активных сессий.
Это самый быстрый и бюджетный способ получить ощутимый прирост производительности без покупки нового ПО. Разберем, как это работает. Вместо того чтобы подключаться к файлу напрямую по сети, мы устанавливаем на сервер веб-сервер (например, Apache 2.4) и публикуем базу через него.
В этом режиме работа происходит следующим образом:
1CD происходит внутри сервера.Важный нюанс: такая схема превращает файловую базу в «квази-серверную». Нагрузка на сеть падает в десятки раз, а проблемы с блокировками SMB исчезают. Однако стоит помнить, что в файловом режиме все равно существует ограничение на количество одновременно работающих пользователей (комфортный предел как раз около 30 человек), и один «тяжелый» отчет может временно заблокировать запись для остальных.
Для 30 активных пользователей нам потребуется собрать сервер, ориентированный на специфику 1С. Рассмотрим ключевые компоненты, на которых нельзя экономить:
Процессор (CPU): Для 1С критически важна частота на одно ядро. Выясним причину: многие операции в 1С выполняются в один поток, и если частота процессора низкая, то даже 40 ядер не спасут от медленного формирования отчета. Проанализируем варианты: отличным выбором станут современные процессоры Intel Core i7 или i9 (с частотой 4.5–5.0 ГГц в Turbo Boost) либо специализированные Intel Xeon Silver/Gold с высокой частотой. Для бюджетных, но производительных сборок хорошо подходят AMD Ryzen 7 второго и третьего поколений.
Оперативная память (RAM): 8 Гб — это вчерашний день. Для комфортной работы 30 пользователей в клиент-серверном варианте (SQL) минимально необходимый объем составляет 32 Гб. Распределим нагрузку:
Дисковая подсистема: Забудьте про HDD. Для базы данных 1С единственным верным решением будет использование SSD NVMe накопителей. Посмотрим на показатели IOPS (количество операций ввода-вывода в секунду): у обычного HDD это около 80-120, у серверного SSD — сотни тысяч. Рекомендуется использовать RAID 1 (зеркало) из двух SSD для отказоустойчивости. Если бюджет позволяет, разделим диски: один под систему, второй под саму базу данных, третий под логи транзакций и временные таблицы tempdb.
Если бюджет позволяет приобрести лицензию на «Сервер 1С:Предприятия», это станет окончательным решением проблем с производительностью. В клиент-серверном варианте база данных хранится не в файле, а в СУБД (Microsoft SQL Server или PostgreSQL).
Разберем преимущества этого подхода:
Для экономии средств часто выбирают PostgreSQL. Однако важно использовать не «чистый» дистрибутив, а сборки, оптимизированные для работы с 1С (например, от Postgres Professional). Рассмотрим пример настройки регламентных заданий для обслуживания базы, которые необходимо выполнять регулярно:
-- Пример команды для обслуживания индексов и сбора статистики в PostgreSQL
VACUUM ANALYZE;
REINDEX DATABASE имя_вашей_базы;
В обсуждениях часто всплывает совет «перевести всех в терминал». Проанализируем ситуацию: для тонкого клиента RDP в большинстве случаев избыточен. Тонкий клиент и так потребляет минимум трафика. Терминал будет полезен только в двух случаях:
Важно понимать: запуск 30 сессий RDP потребует колоссального объема оперативной памяти (каждый пользователь заберет от 500 Мб до 1 Гб RAM на запуск рабочего стола и оболочки), что сделает сервер еще дороже в обслуживании.
После замены железа и настройки веб-сервера или SQL, обратим внимание на настройки ОС, которые часто игнорируют:
.1CD, .1CL, а также каталоги с логами SQL и временными файлами пользователей.Подведем итог: для 30 пользователей оптимальным путем будет связка мощного многопоточного процессора с высокой частотой + 32/64 Гб RAM + NVMe SSD. В качестве программной платформы — Сервер 1С + PostgreSQL. Если бюджет ограничен, временным спасением станет публикация файловой базы на Apache, что уберет сетевые задержки и позволит дождаться закупки полноценного серверного оборудования.