← На главную

Переход со старых конфигураций 1С (например, 1С:Бухгалтерия 2.0 на обычных формах) на современные прикладные решения (такие как 1С:Бухгалтерия 3.0 или отраслевое решение 1С:Бухгалтерия сельскохозяйственного предприятия 3.0 от "Агрософта") часто сопровождается резким падением производительности. Если старая конфигурация "сносно тянула" на древнем оборудовании, то управляемые формы на той же технике начинают работать крайне медленно. В этой статье мы подробно проанализируем причины этой проблемы, разберем методику выбора серверного железа (процессор, оперативная память, дисковая подсистема), а также определим оптимальную архитектуру работы для небольших организаций с числом пользователей от 10 до 12 человек.

В чем причина тормозов управляемых форм на старом железе?

Выясним причину, почему управляемые формы гораздо более требовательны к ресурсам, чем обычные. В старой архитектуре обычных форм основная логика интерфейса выполнялась на стороне клиента. В управляемом приложении (платформа 1С:Предприятие 8.3) вся бизнес-логика и формирование интерфейса происходят на сервере (или эмулируются на стороне клиента, если используется файловая база данных). Это порождает две главные проблемы на устаревшем оборудовании:

1. Огромное потребление оперативной памяти клиентскими сессиями. При работе в терминальном режиме (RDP) каждый запущенный сеанс 1С на управляемых формах потребляет от 400 до 800 Мб оперативной памяти. Если на сервере установлено всего 8 Гб RAM, то при 10–12 пользователях система неизбежно сваливается в своп (начинает использовать жесткий диск как оперативную память), из-за чего работа становится невозможной.
2. Повышенная нагрузка на процессор в один поток. Проведение документов и расчеты в 1С выполняются в один поток. Старые серверные процессоры с большим количеством ядер, но низкой тактовой частотой (например, 2.0–2.2 ГГц) не способны быстро обрабатывать логику управляемых форм.

Выбор процессора: тактовая частота против многоядерности

Рассмотрим подробнее критерии выбора центрального процессора (CPU) для сервера 1С. Распространенная ошибка — покупка многопроцессорных конфигураций с большим количеством ядер, но низкой частотой. Для 1С этот подход губителен.

Для эффективной работы платформы 1С критически важна высокая производительность на одно ядро (Single-Core Performance). Чем выше тактовая частота процессора, тем быстрее будут проводиться документы и формироваться отчеты. Проанализируем требования к процессору:

• Минимальная базовая тактовая частота процессора должна составлять не менее 3.5 ГГц (желательно с поддержкой технологии Turbo Boost до 4.0 ГГц и выше).
• Для 10–12 пользователей нет необходимости в двухпроцессорных конфигурациях. Однопроцессорный сервер на базе современных семейств Intel Xeon E или старших моделей Intel Xeon E5 (например, Xeon E5-1630 v4 с частотой 3.7 ГГц) справится с этой задачей с огромным запасом.
• Использование многоядерных систем (более 8-12 ядер) оправдано только при большом количестве одновременно работающих пользователей (от 30–50 сессий), когда требуется параллельно обрабатывать много независимых запросов к СУБД.

Оперативная память: рассчитываем необходимый объем

Посмотрим, как правильно рассчитать объем оперативной памяти (RAM) для нашего сервера. Допустим, мы планируем использовать терминальный режим (RDP) для 12 пользователей:

1. Операционная система: Windows Server требует для стабильной работы около 4–6 Гб.
2. Терминальные сессии пользователей: 12 пользователей * 800 Мб (максимальный пиковый объем сессии 1С на УФ) = 9.6 Гб.
3. Кэш СУБД или файловой базы: для быстрого чтения данных платформе требуется кэшировать таблицы в оперативной памяти — заложим под это еще 4–8 Гб.

В сумме получаем около 18–24 Гб оперативной памяти. Таким образом, планка в 32 Гб RAM является оптимальным стандартом для сервера на 10–12 пользователей. Покупать сервер с объемом памяти менее 16 Гб под современные конфигурации 1С категорически не рекомендуется.

Дисковая подсистема: почему серверный SSD — это необходимость

Разберем по шагам требования к накопителям. Скорость работы любой базы данных упирается в дисковую подсистему, а именно в показатели времени задержки (latency) и количество операций случайного чтения/записи в секунду (IOPS). Обычные механические жесткие диски (HDD) даже в быстрых SAS-конфигурациях показывают крайне низкие результаты при работе со СУБД.

Для обеспечения комфортной скорости работы базы данных 1С необходимо использовать твердотельные накопители (SSD). Однако здесь кроется важный нюанс: обычные потребительские SSD (десктопные серии) использовать в серверах нельзя. Они лишены защиты от потери питания (Power Loss Protection), из-за чего при любом сбое электросети база данных 1С гарантированно повредится. Кроме того, их ресурс перезаписи (TBW) в условиях постоянных транзакций баз данных исчерпается за несколько месяцев.

Рекомендуется использовать серверные твердотельные накопители класса Enterprise (например, серии Intel DC S3610, Intel DC S3520 или современные NVMe-накопители корпоративного сегмента). Для построения отказоустойчивой дисковой подсистемы применим следующую схему:

• Первый массив (RAID 1 - Зеркало): Два быстрых диска (например, корпоративные WD Gold или надежные SAS HDD) под операционную систему, системный кэш и файлы подкачки.
• Второй массив (RAID 1 - Зеркало): Два серверных SSD под размещение рабочих баз данных 1С и временных файлов (папки Temp).
• Резервное копирование: Отдельный емкий жесткий диск (внутренний или внешний) исключительно для хранения бэкапов. Никогда не храните бэкапы на тех же дисках, где крутится рабочая база данных!

Для управления дисковыми массивами желательно использовать выделенный аппаратный RAID-контроллер со встроенной кэш-памятью и батареей защиты кэша (BBU / Flash Module), например, контроллеры семейства Adaptec. Это обезопасит данные и существенно ускорит операции записи.

Архитектура подключения: RDP против публикации на веб-сервере

Выясним причину, почему традиционный терминальный доступ (RDP) постепенно уступает место альтернативным технологиям подключения в управляемом приложении. При использовании терминала сервер вынужден тратить огромные ресурсы на отрисовку графического интерфейса Windows для каждого пользователя, обслуживание системных процессов Explorer и кэширование временных файлов сессии.

Современная архитектура 1С на управляемых формах предлагает отличную альтернативу — публикацию базы данных на веб-сервере (например, бесплатном веб-сервере Apache 2.4 или встроенном в Windows IIS). Проанализируем схему работы этой технологии:

1. База данных (файловая или серверная) публикуется на веб-сервере, запущенном на серверной машине.
2. На локальных компьютерах пользователей устанавливается легкий дистрибутив Тонкий клиент 1С.
3. При подключении тонкий клиент отправляет легкие http/https-запросы к веб-серверу. Вся графическая оболочка, отрисовка форм и интерфейса выполняются непосредственно на процессоре и оперативной памяти локального компьютера пользователя.
4. Сервер занимается только чистой обработкой данных и выполнением серверных процедур.

Такой подход позволяет полностью разгрузить сервер от графических оболочек пользователей, отказаться от дорогостоящих лицензий на терминальный доступ (RDS CAL) и комфортно работать даже со старых клиентских машин (с процессорами начального уровня и 1–2 Гб оперативной памяти) или через медленные каналы связи (Wi-Fi, удаленные точки доступа).

Файловый режим против клиент-серверного (СУБД) для 10-12 пользователей

Рассмотрим подробнее экономическую и техническую целесообразность покупки полноценного сервера приложений 1С и лицензий на СУБД (например, Microsoft SQL Server). Для небольших баз (объемом до 3–5 Гб) и при небольшом количестве пользователей покупка коммерческих лицензий MS SQL и сервера 1С часто является неоправданной финансовой нагрузкой на бизнес.

В диапазоне 10–12 не слишком активных пользователей (например, классическая бухгалтерия небольшого предприятия) файловый вариант базы данных на производительном сервере с высокочастотным процессором и серверными SSD показывает отличные результаты. Основное ограничение файлового режима — это блокировки на уровне таблиц при одновременной записи данных несколькими пользователями. Если ваши сотрудники не занимаются непрерывной выпиской первичных документов в режиме реального времени, файловый вариант будет работать быстро и стабильно.

Если же в будущем возникнут проблемы с блокировками, отличным решением станет переход на бесплатную СУБД PostgreSQL (а именно на сертифицированную сборку Postgres Pro 1C), которая не требует затрат на покупку лицензий СУБД, но обеспечивает полноценную клиент-серверную архитектуру работы.

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

Проанализируем практический кейс построения сервера для 10 пользователей конфигурации БСХП 3.0 (база файловая, объем около 2.5 Гб), который был реализован и показал отличную производительность.

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

• Процессор: Intel Xeon E5-1630 v4 (базовая тактовая частота 3.7 ГГц, 4 ядра, 8 потоков). Обеспечивает высочайшую скорость работы в однопоточных операциях 1С.
• Оперативная память: 32 Гб RAM (с поддержкой коррекции ошибок ECC).
• RAID-контроллер: Adaptec ASR-8405E v2 со специальным дополнительным охлаждением.
• Диски под систему (RAID 1): Два жестких диска корпоративного класса WD Gold 1Tb.
• Диски под базы данных (RAID 1): Два надежных серверных твердотельных накопителя Intel DC S3610 объемом по 200 Гб каждый.

После развертывания операционной системы и переноса баз данных в терминальном режиме работы было проведено нагрузочное тестирование профессиональным тестом производительности Гилева. Результат теста составил 74 – 78 попугаев, что по шкале оценки производительности классифицируется как "Замечательно". В реальной эксплуатации пользователи отметили мгновенный отклик системы, быстрое проведение тяжелых документов и полное отсутствие зависаний при формировании регламентированных отчетов.