← На главную

Рано или поздно любая растущая компания сталкивается с ситуацией, когда привычная и годами работавшая инфраструктура 1С начинает давать сбои. Типичный пример: сервер на базе процессора Core i3-3220 с 32 ГБ оперативной памяти под управлением устаревшей 32-битной операционной системы Windows Server 2008. На нем крутятся две файловые базы общим объемом 17 ГБ, а 15 пользователей работают через терминальный доступ (RDP). Постоянные зависания, медленная работа, вылеты при формировании тяжелых отчетов с ошибками нехватки памяти — классические симптомы того, что система полностью исчерпала свой ресурс.

В этой статье мы подробно разберем, как решить эту проблему, проанализируем различные варианты модернизации аппаратной и программной части, а также рассмотрим важные технические тонкости, которые помогут сэкономить бюджет и получить колоссальный прирост производительности.

Почему текущая система работает медленно и выдает ошибки?

Давайте проанализируем ситуацию и выясним первопричину проблем. Главный «бутылочный горлышко» в текущей конфигурации — это 32-разрядная операционная система (Windows Server 32-bit).

В 32-битной архитектуре адресное пространство ограничено 4 ГБ. На практике операционная система выделяет под один процесс (например, рабочий процесс 1С или сессию пользователя) не более 2 ГБ (в редких случаях до 3 ГБ при использовании специального ключа разметки памяти). Когда пользователь пытается сформировать тяжелый отчет или выполнить закрытие месяца, объем обрабатываемых данных превышает этот лимит, и платформа аварийно завершает работу с ошибкой нехватки памяти.

Вторая проблема — файловый режим работы баз данных общим объемом 17 ГБ. Файловая СУБД 1С (файл 1Cv8.1CD) отлично работает на базах до 4-6 ГБ с небольшим количеством пользователей. При росте базы до 17 ГБ и 15 активных пользователях конкуренция за доступ к таблицам становится критической. Файловый режим не умеет распараллеливать запросы на запись так, как это делают полноценные СУБД. В итоге пользователи постоянно ждут друг друга (возникают транзакционные блокировки).

Третья проблема — устаревший двухъядерный процессор Core i3-3220 и, скорее всего, медленная дисковая подсистема на классических HDD-накопителях. Терминальный сервер на 15 пользователей сам по себе потребляет значительные ресурсы процессора для отрисовки графического интерфейса сессий Windows.

---

Шаг 1. Переход на 64-битную архитектуру и временное спасение файловой базы

Первое и обязательное действие, с которого необходимо начать — полный переход на 64-разрядную операционную систему (например, Windows Server 2016/2019/2022 x64 или Linux-дистрибутивы) и установку 64-битной платформы 1С. Это сразу решит проблему с падением отчетов из-за нехватки адресного пространства, так как лимит памяти на один процесс в x64 практически отсутствует.

Если прямо сейчас нет возможности быстро перейти на полноценный SQL-вариант, мы можем временно оптимизировать файловую базу. В файловой 1С действует жесткое ограничение: размер любой одной внутренней таблицы базы по умолчанию не может превышать 4 ГБ. При общем объеме базы в 17 ГБ вы рискуете в любой момент получить крах базы данных, если таблица индексов или итогов превысит этот лимит.

Рассмотрим, как это исправить с помощью увеличения размера страницы базы данных. Начиная с платформы 8.3.8, размер страницы внутренней СУБД можно увеличить со стандартных 4 КБ до 64 КБ с помощью утилиты CNVDBFL.exe (она находится в папке bin установленной платформы 1С). Это увеличивает максимальный размер одного внутреннего файла таблицы с 4 ГБ до 6 ГБ.

Выполним процедуру конвертации по шагам:

1. Создайте резервную копию базы данных (скопируйте файл 1Cv8.1CD в безопасное место).
2. Убедитесь, что все пользователи вышли из базы данных и все сеансы завершены.
3. Запустите утилиту CNVDBFL.exe из каталога платформы.
4. В поле «Имя файла базы данных» укажите путь к вашему файлу 1Cv8.1CD.
5. В параметре «Размер страницы» выберите значение 64000 (64 КБ).
6. Нажмите кнопку «Выполнить» и дождитесь окончания процесса.

Этот простой шаг временно убережет базу от разрушения из-за превышения лимита таблиц, но не решит проблему блокировок при совместной работе 15 пользователей. Для полноценного решения необходим переход на клиент-серверный вариант.

---

Шаг 2. Радикальное уменьшение размера базы за счет выноса файлов

Часто файловая база разрастается до внушительных 17 ГБ не из-за документов и проводок, а из-за хранения внутри СУБД прикрепленных файлов: сканов договоров, PDF-документов, картинок номенклатуры. Хранить такие данные внутри базы данных крайне неэффективно.

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

Разберем, как перенести файлы на диск:

1. Перейдите в раздел Администрирование -> Настройки работы с файлами.
2. Установите переключатель «Хранить файлы» в положение В томах на диске.
3. Создайте на сервере быструю папку (желательно на SSD) и настройте к ней общий доступ для учетной записи, под которой запускается служба 1С.
4. В 1С добавьте новый том, указав путь к созданной папке (например, \\server\1c_files\).
5. Запустите типовую обработку по переносу уже существующих файлов из базы данных в созданные тома.

После переноса файлов база данных объемом 17 ГБ может уменьшиться до 3–5 ГБ. Это не только колоссально ускорит работу СУБД (так как таблицы станут компактными, индексы будут легко помещаться в кэш), но и сократит время создания резервных копий в разы.

---

Шаг 3. Переход на СУБД PostgreSQL/Postgres Pro — экономия на лицензиях MS SQL

В обсуждениях часто упоминают MS SQL Server, однако покупка лицензий MS SQL Server и клиентских лицензий доступа (CAL) для небольших компаний экономически нецелесообразна и выливается в огромные бюджеты.

Отличной бесплатной альтернативой является СУБД PostgreSQL (а именно отечественная сборка Postgres Pro, специально оптимизированная и сертифицированная для работы с платформой 1С). Она не имеет ограничений по объему баз данных, количеству используемых ядер процессора и оперативной памяти, при этом платить за лицензии СУБД не нужно вообще.

Для 15 пользователей связка 64-битного сервера приложений 1С и СУБД Postgres Pro на современном оборудовании покажет производительность, практически не уступающую MS SQL Server.

При переходе на клиент-серверный вариант вам потребуется приобрести только одну серверную лицензию 1С. Обратите внимание: недорогой вариант «1С:Предприятие 8.3. Сервер МИНИ на 5 подключений» в данном случае не подойдет, так как у вас 15 активных пользователей, а лицензия МИНИ жестко ограничивает число сессий до 5. Потребуется покупка полноценной лицензии «1С:Предприятие 8.3 ПРОФ на 64-разрядный сервер».

---

Шаг 4. Отказ от RDP и терминальных лицензий через публикацию на веб-сервере

Терминальный доступ (RDP) создает огромную нагрузку на сервер. Каждая открытая сессия пользователя — это запущенный графический интерфейс Windows, службы печати, буфер обмена и другие процессы, которые отнимают драгоценные гигабайты оперативной памяти и такты процессора. Кроме того, для легальной работы требуются дорогостоящие терминальные лицензии Microsoft RDS CAL.

Мы можем полностью отказаться от RDP для тех пользователей, которые работают с управляемыми формами (УФ). Для этого выполним публикацию базы данных на бесплатном веб-сервере (например, Apache или встроенном в Windows IIS).

Схема работы выглядит следующим образом:

1. На сервере настраивается и запускается веб-сервер Apache.
2. В конфигураторе 1С под правами администратора выбирается пункт меню Администрирование -> Публикация на веб-сервере.
3. Указывается имя публикации, выбирается установленный веб-сервер и нажимается кнопка «Опубликовать».
4. На локальных компьютерах пользователей устанавливается легкий и бесплатный «Тонкий клиент 1С».
5. В окне запуска 1С на рабочих станциях добавляется новая база с типом подключения «Веб-сервер» и указывается ссылка вида http://имя_сервера/имя_публикации.

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

---

Шаг 5. Оптимизация Shared Memory при совместном размещении СУБД и сервера 1С

Если вы выберете наиболее жизнеспособный и экономичный Вариант 1 (когда и сервер приложений 1С, и СУБД Postgres/MS SQL находятся на одном физическом новом сервере), обязательно задействуйте оптимизацию передачи данных через общую память (Shared Memory).

По умолчанию сервер приложений 1С общается с СУБД по сетевому протоколу TCP/IP, даже если они запущены на одном компьютере. Это заставляет пакеты данных проходить через сетевой стек операционной системы, что создает лишние задержки.

Использование протокола Shared Memory исключает сетевой стек из цепочки обмена данными и ускоряет выполнение запросов к базе данных на 10–15%.

Для MS SQL Server это настраивается в утилите SQL Server Configuration Manager (в разделе Client Protocols и Protocols для вашего экземпляра нужно включить «Shared Memory»). В строке подключения к серверу СУБД в кластере 1С в таком случае в качестве имени сервера СУБД следует указывать локальное имя компьютера или точку (.), либо явно задавать протокол, например:

lpc:Имя_Вашего_Сервера ---

Шаг 6. Критический анализ оборудования: почему Xeon v2 — это ошибка?

На форумах часто советуют сэкономить и модернизировать старый сервер на сокете LGA 1155, установив туда бывший в употреблении процессор семейства Xeon (например, Xeon E3-1270 v2 или E3-1230 v2), добавив SSD-диски.

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

Процессоры линейки Xeon E3-1200 v2 вышли в далеких 2012–2013 годах. Их архитектура давно устарела, а тактовая частота и показатель IPC (количество инструкций за такт) крайне низки по сравнению с современными процессорами. Установка такого процессора даст прирост только за счет большего количества ядер/потоков по сравнению с вашим старым Core i3-3220 (что немного облегчит жизнь терминальным пользователям), но индивидуальная скорость проведения документов и формирования отчетов останется на прежнем низком уровне.

Для действительно быстрой работы 1С гораздо эффективнее приобрести современный сервер на базе «бытовых» процессоров с высокой производительностью на одно ядро (например, современных поколений Intel Core i5/i7 или AMD Ryzen) с базовой частотой от 3.6–4.0 ГГц и выше, либо современные серверные процессоры Intel Xeon Silver / Gold последних поколений с высокой частотой работы ядер.

Также критически важно использовать современные высокоскоростные твердотельные накопители NVMe PCIe SSD (желательно в отказоустойчивом RAID-1 массиве) вместо старых SATA SSD или тем более классических жестких дисков HDD. Скорость случайного чтения и записи (IOPS) на таких накопителях в десятки раз выше, что мгновенно уберет задержки при работе с базой данных.

---

Резюме: идеальная стратегия апгрейда

Подведем итог и составим пошаговый план модернизации вашей системы:

1. Аппаратная часть: Приобретаем новый физический сервер (или собираем производительный ПК-сервер) на базе современного процессора с высокой частотой на одно ядро (от 3.6 ГГц и выше) и быстрыми NVMe SSD-накопителями в зеркальном RAID-массиве. Объем ОЗУ — от 32 до 64 ГБ.
2. Операционная система: Устанавливаем современную 64-битную ОС (Windows Server x64 или Linux).
3. Программная часть: Переносим базы на бесплатную СУБД Postgres Pro. Приобретаем 64-битную лицензию на сервер 1С ПРОФ.
4. Оптимизация баз: Настраиваем хранение прикрепленных файлов в томах на диске для уменьшения размера баз данных.
5. Доступ пользователей: Публикуем базы на веб-сервере (Apache/IIS). Переводим всех пользователей управляемых форм на Тонкий клиент 1С через HTTP/HTTPS, полностью отказавшись от дорогостоящего и ресурсоемкого RDP. Для старых баз на обычных формах (если они есть) оставляем терминальный доступ в минимальном объеме.
6. Тонкая настройка: Если сервер 1С и Postgres работают на одной машине, настраиваем их взаимодействие через протокол Shared Memory.

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