Медленная работа системы «1С:Предприятие» при подключении через веб-сервер — одна из самых распространенных проблем, с которой сталкиваются системные администраторы и разработчики. Ситуация часто осложняется тем, что классические методы «железного» апгрейда (покупка многоядерных процессоров, увеличение объема оперативной памяти) не приносят ожидаемого эффекта. Пользователи продолжают жаловаться на зависания интерфейса, особенно в пиковые часы работы.
В этой статье мы подробно разберем, как выжать максимум производительности из связки веб-сервера и «1С» как в файловом варианте, так и при переходе на SQL. Мы проанализируем неочевидные тонкости настроек веб-серверов Apache и IIS, решим проблему зависания поиска в Рабочем месте кассира (РМК), разберем мифы о разгоне оборудования и укажем на опасные методы оптимизации, которые могут привести к потере данных.
Типичная ситуация, которую описывают многие администраторы: на сервере установлен производительный процессор, быстрый SSD-накопитель и достаточный объем оперативной памяти, но при запуске тяжелых отчетов или во время активной работы кассиров диспетчер задач показывает нагрузку на процессор и диск не более 20–60%. Почему так происходит?
Рассмотрим природу работы файловой СУБД .1cd. В файловом варианте «1С:Предприятия» отсутствует полноценный сервер управления базами данных, который мог бы распределять запросы на уровне отдельных записей (строк таблиц). Вместо этого при выполнении любой транзакции записи (например, проведение чека ККМ или запись документа) платформа накладывает блокировку на всю таблицу целиком.
В этот момент происходит следующее:
Таким образом, физический разгон процессора или увеличение частоты оперативной памяти не помогут решить проблему конкурентных табличных блокировок в файловой базе. Для исправления ситуации требуются иные методы оптимизации.
Зависание интерфейса на 3–5 секунд при поиске номенклатуры в Рабочем месте кассира (РМК) — критический фактор для розничной торговли, приводящий к очередям. Разберем по шагам, как локализовать и устранить эту проблему без изменения кода конфигурации.
Шаг 1. Настройка Полнотекстового поиска (ПТП)
В современных конфигурациях «1С» (включая «1С:Розница» и «1С:Управление нашей фирмой») механизм поиска по умолчанию опирается на индекс полнотекстового поиска. Если данный индекс не обновляется своевременно или поврежден, система начинает выполнять тяжелые последовательные запросы к базе данных, сканируя все текстовые поля.
Выполним обслуживание индекса ПТП:
Шаг 2. Ограничение полей поиска в РМК
Часто система пытается искать совпадения по всем доступным реквизитам справочника «Номенклатура», включая длинные текстовые описания товаров, артикулы поставщиков и дополнительные свойства. Нам необходимо зайти в настройки РМК (или настройки параметров учета) и жестко ограничить критерии поиска. Оставим активными только наиболее важные поля: Код, Артикул, Штрихкод и Наименование.
Шаг 3. Настройка сканера штрихкодов
Проанализируем режим работы торгового оборудования. Если сканер штрихкодов подключен в режиме «разрыва клавиатуры» (Keyboard Emulation), то при сканировании штрихкода он эмулирует последовательное нажатие клавиш на клавиатуре. При этом платформа «1С» воспринимает ввод каждого символа как отдельное действие пользователя и может инициировать микро-запросы к базе данных на каждый введенный символ.
Рекомендуется перевести сканер штрихкодов в режим эмуляции COM-порта (виртуальный COM-порт через USB) с установкой соответствующего драйвера в «1С». В этом случае штрихкод будет передаваться в систему мгновенно и целиком как единое событие, вызывая ровно один быстрый запрос к базе данных.
Если веб-сервер Apache настроен со стандартными параметрами «из коробки», он не сможет эффективно обрабатывать параллельные запросы от тонких клиентов «1С». Проведем оптимизацию конфигурационного файла httpd.conf.
Рассмотрим подробнее ключевые параметры:
1. Настройка удержания соединения (KeepAlive)
Тонкий клиент «1С» постоянно обменивается с сервером множеством мелких пакетов. Если параметр KeepAlive отключен, сервер будет закрывать TCP-соединение после каждого микро-запроса, тратя ресурсы на повторную авторизацию и установку сессии.
Включим этот механизм, добавив или изменив следующие директивы в httpd.conf:
KeepAlive On
MaxKeepAliveRequests 500
KeepAliveTimeout 15
2. Оптимизация многопоточности для Windows (модуль mpm_winnt)
Поскольку веб-сервер в нашем случае работает под управлением ОС Windows, за обработку потоков отвечает модуль mpm_winnt_module. Нам необходимо увеличить количество одновременно обрабатываемых потоков, чтобы избежать очередей на стороне веб-сервера.
Найдем в конфигурационном файле соответствующий блок и приведем его к следующему виду:
<IfModule mpm_winnt_module>
ThreadsPerChild 150
MaxConnectionsPerChild 0
</IfModule>
Параметр ThreadsPerChild 150 указывает веб-серверу на создание 150 постоянных потоков для обработки запросов клиентов, что полностью перекрывает потребности небольшого офиса. Параметр MaxConnectionsPerChild 0 предотвращает принудительный перезапуск рабочих потоков при достижении лимита подключений.
3. Включение сжатия данных (mod_deflate)
Тонкий клиент обменивается с веб-сервером текстовыми данными формата XML и JSON. Включение сжатия «на лету» позволяет снизить объемы передаваемого трафика в несколько раз, что особенно заметно на тонких каналах связи и мобильном интернете.
Раскомментируем строку подключения модуля сжатия в httpd.conf:
LoadModule deflate_module modules/mod_deflate.so
И настроим типы данных, подлежащие сжатию:
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/json
AddOutputFilterByType DEFLATE text/html text/xml text/css text/javascript
</IfModule>
Многие специалисты на практике отмечают, что под управлением ОС Windows веб-сервер IIS демонстрирует более стабильную работу с программными лицензиями «1С» и реже «теряет» сеансы пользователей по сравнению с Apache. Рассмотрим основные шаги по оптимизации IIS для работы с «1С»:
DefaultAppPool).20 на 0. Это предотвратит «засыпание» рабочего процесса IIS при отсутствии активности (например, в периоды затишья на кассах), исключая долгую инициализацию первого подключения после простоя.0 (отключить принудительный перезапуск посреди рабочего дня). Перезапуск пула лучше настроить по фиксированному расписанию (например, в 3:00 ночи) во вкладке Запуски (Recycling).При публикации информационной базы на веб-сервере платформа создает конфигурационный файл default.vrd. В нем можно вручную задать параметры пула соединений с базой данных, что позволит сократить время отклика системы.
Откроем файл default.vrd, расположенный в каталоге публикации базы, текстовым редактором и отредактируем параметры корневого тега point:
<point xmlns="http://v8.1c.ru/8.2/uap/vrd"
base="/BaseName"
ib="File="C:\Bases\Base1C";"
poolSize="20"
poolTimeout="60">
Рассмотрим подробнее эти параметры:
poolSize="20" — указывает веб-серверу удерживать в памяти до 20 открытых соединений к файлу базы данных. Благодаря этому при действиях пользователя системе не требуется тратить время на повторное монопольное открытие физического файла базы.poolTimeout="60" — время (в секундах), в течение которого неиспользуемое соединение удерживается в пуле перед уничтожением.В попытках ускорить файловую базу администраторы прибегают к экстремальным методам: созданию RAM-диска в оперативной памяти (например, с помощью ImDisk) или использованию утилит отложенной записи на физический диск (например, PrimoCache). При этом тесты дисковой подсистемы (CrystalDiskMark) показывают фантастические результаты, но использовать такие методы для хранения баз данных «1С» категорически запрещено по следующим причинам:
При включении механизма отложенной записи (Write-deferred) операционная система подтверждает программе успешное сохранение данных сразу после их записи в быструю оперативную память, в то время как физическая запись на SSD-накопитель происходит с задержкой в несколько секунд или даже минут.
Если в этот промежуток времени произойдет любой из следующих сбоев:
Структура файловой базы данных .1cd будет мгновенно и безвозвратно разрушена. Таблицы транзакций окажутся рассинхронизированы, и базу будет невозможно восстановить даже с помощью утилиты тестирования и исправления chdbfl.exe.
Безопасная альтернатива:
Используйте RAM-диск исключительно для хранения временных файлов операционной системы (переменные окружения TEMP и TMP) и кэша веб-публикаций. Саму базу данных храните только на надежных твердотельных накопителях (SSD) корпоративного класса с аппаратной технологией защиты от потери питания (PLP — Power Loss Protection).
Когда возможности оптимизации файловой базы исчерпаны, единственным надежным решением для обеспечения параллельной работы пользователей становится перевод базы в клиент-серверный режим (SQL).
В теме на форуме часто советуют приобрести «1С:Предприятие 8. Сервер МИНИ» как недорогой способ перехода на клиент-сервер. Однако необходимо помнить о жестком лицензионном ограничении этого продукта:
Сервер МИНИ поддерживает работу не более 5 сеансов пользователей в одной информационной базе.
Если у вас 6 активных клиентов (как у автора темы), то шестой пользователь физически не сможет зайти в систему, получив ошибку лицензирования. В такой ситуации покупка Сервера МИНИ окажется пустой тратой бюджета. Вам потребуется полноценная лицензия на сервер «1С:Предприятия» (x86-64).
Что касается выбора СУБД:
Переход на клиент-серверную архитектуру исключает возникновение взаимных табличных блокировок файлового режима. СУБД блокирует данные на уровне отдельных строк, что позволяет кассирам проводить чеки параллельно, полностью устраняя задержки интерфейса.
Чтобы доказать руководству необходимость перехода на полноценный сервер «1С» и СУБД, мы можем наглядно зафиксировать время, которое пользователи проводят в ожидании блокировок таблиц. Для этого настроим Технологический журнал платформы.
Создадим текстовый файл с именем logcfg.xml и поместим его в каталог настроек платформы (например, C:\Program Files\1cv8\conf\):
<config xmlns="http://v8.1c.ru/v8/tech-journal">
<log history="24" location="C:\1C_Logs">
<event>
<eq property="Name" value="TLOCK"/>
</event>
<event>
<eq property="Name" value="TTIMEOUT"/>
</event>
<property name="all"/>
</log>
</config>
Проанализируем параметры созданного файла конфигурации:
location="C:\1C_Logs" указывает каталог на жестком диске, куда будут записываться лог-файлы ТЖ. Убедитесь, что у службы, под которой запущен веб-сервер, есть права на запись в эту папку.TLOCK фиксирует все случаи установки транзакционных блокировок в системе.TTIMEOUT регистрирует критические ситуации, когда пользователь не дождался освобождения заблокированного ресурса и система завершила операцию по тайм-ауту.Спустя день активной работы пользователей откройте созданные файлы логов. Наличие множества записей событий TLOCK длительностью более 1–2 секунд станет неопровержимым доказательством того, что файловая база данных исчерпала свой ресурс параллельной работы, и компании требуется переход на СУБД.