← На главную

Проблема «подвисания» рабочего места кассира (РМК) — одна из самых критичных для розничной торговли. Задержка в 5–10 секунд при сканировании каждого товара превращает процесс продажи в испытание для кассира и очереди. Особенно остро это проявляется в конфигурации 1С:Управление торговлей 11 (УТ 11), которая изначально более «тяжелая» по сравнению с узкоспециализированной 1С:Розницей. Разберем по шагам, почему возникают задержки и как оптимизировать систему для мгновенного отклика.

Анализ аппаратной части: проблема низкой частоты процессора

Проанализируем технические данные сервера, предоставленные в обсуждении. Одной из главных причин «тормозов» интерфейса 1С является низкая тактовая частота процессора в момент выполнения операции. В логах сервера Intel Xeon E5-2678 v3 мы видим значения частоты cpu MHz : 1200 при базовой частоте 2.5 GHz. Это явный признак того, что включены режимы энергосбережения.

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

1. Настройка BIOS: Переведем сервер в режим Maximum Performance. Необходимо отключить параметры C-States, P-States и Intel SpeedStep.
2. Настройка ОС Linux (Debian): Посмотрим на текущий регулятор частоты. По умолчанию часто стоит powersave или ondemand. Установим режим максимальной производительности: echo "performance" | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

Это заставит ядра процессора постоянно работать на максимальной частоте, что мгновенно сократит время выполнения серверных вызовов в РМК.

Оптимизация дисковой подсистемы и СУБД PostgreSQL

Проанализируем структуру дисков из примера. Мы видим, что база данных находится на LVM-разделе debian--vg-varlibpostgresql, который физически расположен на md0 — RAID 10 из обычных HDD-дисков (sda, sdb, sdc, sdd). При этом в системе присутствуют незадействованные или выделенные под другие нужды NVMe-накопители (nvme0n1, nvme1n1).

Размещение БД на HDD — это «бутылочное горлышко» для высоконагруженной розницы. Каждое пробитие чека инициирует запись в несколько таблиц и регистров. Рассмотрим план действий по ускорению СУБД:

1. Перенос базы на NVMe: Настоятельно рекомендуем перенести рабочую базу и логи транзакций PostgreSQL на зеркало (RAID 1) из NVMe-дисков. Это даст колоссальный прирост скорости на операциях записи (INSERT/UPDATE).
2. Тюнинг PostgreSQL: Отредактируем файл postgresql.conf. Особое внимание уделим параметру synchronous_commit. Если его установить в значение off, система не будет ждать физической записи на диск для подтверждения транзакции, что ускорит пробитие чеков в несколько раз.
   Скопировать код

   
   shared_buffers = 4GB (или 25% от ОЗУ)
   temp_buffers = 256MB
   work_mem = 64MB
   maintenance_work_mem = 512MB
   effective_cache_size = 12GB
   synchronous_commit = off
   autovacuum = on
   

Оптимизация поиска по штрихкоду в 1С

Как отметил автор темы, основное время уходит на поиск по штрихкоду или DataMatrix. В УТ 11 при большом количестве записей в регистре сведений ШтрихкодыНоменклатуры (сотни тысяч и более) стандартные механизмы могут замедляться. Разберем причины:

Во-первых, проверим настройки РМК. Если включен поиск по части строки (подстроке), то вместо эффективного поиска по индексу СУБД выполняет полное сканирование таблицы. Необходимо убедиться, что поиск в настройках номенклатуры и РМК ограничен полным совпадением.

Во-вторых, проанализируем работу с маркированным товаром. При сканировании кода маркировки (DataMatrix) система не только ищет товар, но и разбирает структуру кода. Выясним, не включена ли онлайн-проверка кодов маркировки в настройках интеграции с ИС МП (Честный Знак). Если она включена, 1С при каждом сканировании «стучится» на сервера ГИС МТ. При любых проблемах с интернетом или нагрузке на сервера проверки возникают задержки по 5–30 секунд.

Рекомендуем настроить кэширование результатов проверки или отключить обязательную проверку в момент сканирования, если это допустимо бизнес-процессом, оставив проверку только в момент закрытия чека.

Проблема драйверов торгового оборудования

Иногда причина кроется не в коде 1С, а во взаимодействии с оборудованием. Разберем два важных момента:

1. Задержки драйвера ККТ: Некоторые версии драйверов (например, АТОЛ) могут иметь встроенные задержки или специфические настройки таймаутов. Проанализируем лог драйвера ККТ. Если там видны паузы перед командами OpenCheck или Registration, проблема в связи с кассой.
2. Режим работы сканера: Если сканер работает в режиме «эмуляции клавиатуры», 1С вынуждена перехватывать ввод каждого символа, что нагружает интерфейсный поток. Переведем все сканеры в режим Native POS (эмуляция COM-порта). Это позволит 1С получать штрихкод целиком как единое событие, что гораздо быстрее и надежнее.

Использование замера производительности для поиска узких мест

Если вышеперечисленные меры не помогли, воспользуемся штатным инструментом Замер производительности. Проделаем следующие шаги:

1. Откроем РМК под пользователем.
2. Включим замер производительности в меню Сервис — Параметры — Отладка (если база файловая или запущен сервер с ключом -debug).
3. Сканируем товар и ждем завершения зависания.
4. Останавливаем замер и анализируем колонку «Чистое время».

Чаще всего в топе оказываются методы, связанные с проверкой остатков, расчетом автоматических скидок или поиском в регистре штрихкодов. Если мы видим, что время тратится на функцию НайтиПоШтрихкоду(), значит, проблема в индексах базы данных. В этом случае поможет реиндексация таблиц через ТииС (Тестирование и исправление) или средствами СУБД (REINDEX).

Резюме: контрольный список действий

Чтобы РМК в УТ 11 работало быстро, выполним последовательно:

• Железо: Включаем режим High Performance в BIOS и ОС.
• Диски: Переносим базу PostgreSQL на NVMe.
• СУБД: Настраиваем synchronous_commit = off.
• 1С: Отключаем онлайн-проверку марок при сканировании и поиск по подстроке.
• Оборудование: Переводим сканеры в COM-режим.

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