Как устранить сильные тормоза 1С на терминальном сервере и стоит ли переходить на клиент-серверный вариант?

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

В этой статье мы подробно проанализируем реальный кейс: терминальный сервер с 8–10 пользователями, у каждого из которых открыто от 3 до 5 баз (размером от 3 до 6 Гб). Базы начали катастрофически зависать после очередного обновления платформы. Мы разберем по шагам, как локализовать проблему, настроить операционную систему, оптимизировать саму платформу 1С и принять обоснованное решение — оставаться на файловой версии или переходить на клиент-серверный вариант.

Шаг 1. Анализ влияния версии платформы 1С и откат на стабильный релиз

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

Если после обновления на платформу 8.3.16.x вы заметили резкое снижение быстродействия, выполним следующие действия:

1. Выясним минимально допустимую версию платформы для вашей текущей конфигурации 1С (эта информация всегда указывается в файле описания обновления ReadMe.txt или на портале ИТС).
2. Если конфигурация (например, «1С:Бухгалтерия») требует платформу не ниже 8.3.15.1830, не нужно без крайней необходимости устанавливать 8.3.16 или более новые сборки.
3. Проведем технологический откат: установим стабильный релиз из предыдущей ветки — например, 8.3.15.1869. Как показывает практика, один только этот шаг позволяет мгновенно вернуть производительность системы к прежним комфортным показателям.

Шаг 2. Аппаратная модернизация: дисковая подсистема (SSD) и оперативная память

Проанализируем аппаратную конфигурацию сервера. Файловая 1С критически чувствительна к скорости дисковых операций (показателю IOPS) и объему свободной оперативной памяти. Работа в терминальном режиме на обычном жестком диске (HDD) — это главная системная ошибка.

Выполним модернизацию дисков по следующей схеме:

1. Полностью откажемся от HDD для рабочих баз и операционной системы. Жесткие диски (такие как популярные накопители серии Seagate BarraCuda или аналогичные) должны использоваться исключительно для хранения архивных копий (бэкапов).
2. Установим твердотельные накопители (SSD). В идеале сервер должен быть укомплектован двумя отдельными массивами RAID 1 (зеркало):
   • Первый RAID-массив (SSD) — под операционную систему Windows Server и файл подкачки.
   • Второй RAID-массив (SSD) — исключительно под рабочие базы данных 1С.
3. Увеличим объем оперативной памяти (ОЗУ). Если на сервере активно работают 10 пользователей, и у каждого открыто по 3–5 баз, то общее количество запущенных сессий процессов 1cv8.exe может достигать 30–50 штук. Каждая открытая база в файловом режиме потребляет от 300 до 800 Мб оперативной памяти. Лимит в 16 Гб ОЗУ в таких условиях исчерпывается мгновенно, после чего операционная система начинает активно сбрасывать данные в файл подкачки (swapping) на диск, парализуя работу процессора. Для такой нагрузки минимально необходимый объем памяти составляет 32 Гб, а рекомендуемый — 64 Гб.

Шаг 3. Переход на тонкие клиенты и публикация баз на веб-сервере (IIS / Apache)

Если бюджет компании ограничен и покупка серверных лицензий 1С пока не планируется, рассмотрим отличную альтернативу — запуск баз через веб-сервер. По умолчанию пользователи в терминальной сессии запускают так называемый «толстый» или стандартный тонкий клиент в режиме прямого доступа к файлу базы данных 1Cv8.1CD. Это заставляет сервер тратить ресурсы на отрисовку графического интерфейса каждого пользователя внутри RDP-сессии.

Мы можем разгрузить сервер, переведя пользователей на работу через веб-публикацию:

1. Установим и настроим бесплатный веб-сервер IIS (Internet Information Services), входящий в состав Windows Server, или Apache.
2. Опубликуем наши файловые базы данных на веб-сервере.
3. Настроим запуск 1С на локальных компьютерах сотрудников через Тонкий клиент, указав в качестве пути к базе URL-адрес веб-сервера (например, http://server_name/base_work).

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

Шаг 4. Оптимизация файловой базы: формат журнала регистрации и размер страницы

Проанализируем состояние самих файловых баз данных. Зачастую базы сильно «раздуваются» после обновлений. Помимо регламентного тестирования и исправления (ТИИ), которое действительно необходимо проводить при подозрении на логические ошибки, следует обратить внимание на следующие технические параметры:

1. Оптимизация формата журнала регистрации. Начиная с версии 8.3.5, 1С по умолчанию создает журнал регистрации в формате SQLite (файл 1Cv8.lgp заменяется на 1Cv8.lgd). При интенсивной многопользовательской работе этот файл начинает блокировать базу. Попробуем вернуть старый текстовый формат журнала. Для этого в конфигурационном файле conf.cfg (находится в каталоге установки платформы 1С) добавим строку:

KeepLogFormat=LogAndLogGst

Это позволит снизить количество транзакционных блокировок при записи событий в журнал.

2. Изменение размера страницы базы данных с помощью утилиты cnvdbfl.exe. По умолчанию размер страницы файловой базы составляет 4 Кб. Если размер вашей базы превышает 4 Гб, настоятельно рекомендуется увеличить размер страницы до 64 Кб. Это не только ускорит чтение/запись данных за счет выравнивания блоков на SSD, но и увеличит максимальный лимит размера одной таблицы с 4 Гб до 64 Гб, предотвращая аварийное завершение работы при обновлениях.

Для этого выполним следующие действия в командной строке:

1. Создадим резервную копию базы данных.
2. Запустим утилиту конвертации из папки bin установленной платформы 1С:

"C:\Program Files\1cv8\8.3.15.1869\bin\cnvdbfl.exe" -c -s 64k "D:\1C_Bases\Accounting\1Cv8.1CD"

Шаг 5. Отключение службы «справедливого распределения ресурсов» (Fair Share) в Windows Server

В операционных системах Windows Server, начиная с версии 2012, по умолчанию включена технология Dynamic Fair Share Scheduling (DFSS). Ее задача — предотвратить монополизацию ресурсов процессора или диска одним пользователем терминала. Однако для 1С эта служба работает во вред: как только один из бухгалтеров запускает тяжелый отчет или проведение документов, Windows Server искусственно ограничивает дисковый поток и процессорное время для его сессии. В результате 1С зависает намертво, хотя сам сервер может быть загружен всего на 15–20%.

Рекомендуется отключить эту функцию через системный реестр:

1. Откроем редактор реестра (regedit).
2. Перейдем в ветку: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Quota System. Изменим значение параметра EnableCpuQuota на 0.
3. Перейдем в ветку: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TSFairShare\Disk. Изменим параметр EnableFairShare на 0 (это наиболее критичный параметр для дисковой активности файловой 1С).
4. Перезагрузим терминальный сервер для применения изменений.

Шаг 6. Настройка антивируса и файловой системы NTFS

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

Настроим исключения в антивирусе. Добавим в список доверенных зон (исключений из сканирования в реальном времени):

• Расширения файлов баз и блокировок: *.1CD, *.1CL, *.lgp, *.lgd.
• Каталоги установки платформы: C:\Program Files\1cv8\ и C:\Program Files (x86)\1cv8\.
• Временные папки пользователей (кэш 1С): %USERPROFILE%\AppData\Local\1C\ и %USERPROFILE%\AppData\Roaming\1C\.

Также оптимизируем работу файловой системы NTFS на диске с базами данных. По умолчанию Windows при каждом обращении к файлу перезаписывает метку времени последнего доступа (Last Access Time). Отключим эту функцию, выполнив в командной строке с правами администратора следующую команду:

fsutil behavior set DisableLastAccess 1

Шаг 7. Переход на полноценную клиент-серверную версию 1С

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

При переходе на клиент-серверную версию рассмотрим два варианта:

1. Платный стек (MS SQL Server): Требует покупки сервера 1С, лицензий MS SQL Server и клиентских лицензий доступа (CAL). Это надежное, но дорогостоящее решение.
2. Бесплатный стек (PostgreSQL + Linux/Windows): Позволяет полностью избежать затрат на покупку СУБД. Специальные сборки PostgreSQL, оптимизированные для работы с 1С (например, от Postgres Professional), распространяются бесплатно и обеспечивают великолепное быстродействие. Вы можете развернуть сервер 1С на Windows Server, а в качестве СУБД использовать бесплатный PostgreSQL, настроив регламентные планы обслуживания (реиндексация, обновление статистики) по стандартным инструкциям ИТС.

Подведем итог. Начните оптимизацию с простых бесплатных шагов: откатитесь на стабильную 15-ю платформу, настройте исключения антивируса, отключите Fair Share в реестре Windows и перенесите базы на SSD. Если этих мер окажется недостаточно — планируйте поэтапный переход на клиент-серверную версию с использованием СУБД PostgreSQL.