Рано или поздно любой системный администратор или программист 1С сталкивается с ситуацией, когда стабильно работающая годами система начинает «подтормаживать». Пользователи жалуются на медленный запуск программы, задержки при поиске номенклатуры и зависания интерфейса в момент сканирования штрихкодов. Особенно остро эта проблема проявляется в связке платформы 1С:Предприятие 8.3 (например, релиз 8.3.13) с конфигурацией «Управление торговлей» (УТ 11) и СУБД PostgreSQL.
Обычная перезагрузка сервера или разовый запуск очистки базы данных дают лишь временный эффект. Выясним истинные причины падения производительности и разберем по шагам комплексное решение этой проблемы: от настройки интерфейса 1С до глубокой оптимизации параметров PostgreSQL.
Когда пользователи жалуются на общие зависания, первым делом необходимо запустить замер производительности в конфигураторе. Проанализируем реальный сценарий: замер показывает, что около 70% времени выполнения операций уходит на следующую строку кода при открытии рабочего места кассира (РМК) или чека ККМ:
ПараметрыФормы = Новый Структура;
ОткрытьФорму("Обработка.ПодборТоваровВДокументПродажи.Форма", ПараметрыФормы, ЭтотОбъект, УникальныйИдентификатор);
Почему форма подбора товаров в УТ 11 начинает со временем открываться всё дольше? Дело в том, что эта форма построена на базе динамических списков, которые «на лету» выполняют сложные запросы к базе данных. Система пытается одновременно рассчитать свободные остатки на складах, резервы, характеристики номенклатуры и актуальные цены по выбранному виду цен.
Рассмотрим подробнее два эффективных способа оптимизации этой формы:
РегистрСведений.ЦеныНоменклатуры, исправьте некорректные даты и при необходимости произведите свертку старых записей.Жалобы продавцов на «зависание программы при сканировании штрихкодов» — классическая проблема розничной торговли. Источник этой беды чаще всего кроется в физическом способе подключения оборудования.
Посмотрим, как настроен сканер штрихкодов. Если он работает в режиме эмуляции клавиатуры (KB), то при сканировании код передается в систему посимвольно — так, словно кассир с невероятной скоростью нажимает клавиши. Если работа происходит в терминальной сессии (RDP), сетевые задержки приводят к потере пакетов и «заиканию» интерфейса. 1С пытается обработать каждое нажатие отдельно, зависает и тормозит работу.
Чтобы решить эту проблему, выполним следующие действия:
Также стоит помнить о старой системной ошибке в коде типовых конфигураций: если сканируется неизвестный штрихкод, система может инициировать полнотекстовый поиск по всей базе. Убедитесь, что индекс полнотекстового поиска регулярно обновляется регламентным заданием, либо временно отключите его в разделе администрирования, если он не используется сотрудниками.
Выполнение ручной команды VACUUM FULL + ANALYZE временно решает проблему производительности. Эта операция полностью перестраивает таблицы базы данных, удаляет «мертвые» строки (bloat) и обновляет статистику для планировщика запросов. Однако без правильной настройки конфигурационного файла СУБД postgresql.conf база начнет тормозить снова уже через пару недель.
Настроим PostgreSQL под требования 1С правильно. Для этого откроем конфигурационный файл и внесем изменения в ключевые параметры:
По умолчанию в стандартных настройках PostgreSQL автоматическая очистка запускается слишком редко — только когда в таблице изменяется более 20% записей. Для крупных таблиц итогов и регистров 1С это критично: таблицы успевают колоссально «раздуться», прежде чем запустится очистка. Изменим эти лимиты:
autovacuum_vacuum_scale_factor = 0.05
autovacuum_analyze_scale_factor = 0.025
Эти параметры заставят СУБД запускать очистку мелких порций данных незаметно для пользователей, как только изменится 5% записей в таблице, и обновлять статистику при изменении 2.5% строк.
Платформа 1С активно создает временные таблицы СУБД при работе с динамическими списками, проведении документов и генерации отчетов. Если под эти задачи выделено мало оперативной памяти, PostgreSQL будет сбрасывать промежуточные данные на медленный жесткий диск. Оптимизируем параметры памяти:
temp_buffers = 128MB
work_mem = 64MB
Увеличение temp_buffers позволит обрабатывать временные таблицы непосредственно в ОЗУ, существенно сокращая время дисковых операций ввода-вывода (I/O).
Если вы используете специализированную сборку PostgreSQL для 1С (например, от Postgres Pro), обязательно убедитесь, что в файле конфигурации подключен плагин online_analyze. Он позволяет собирать актуальную статистику по временным таблицам прямо во время выполнения транзакции, не дожидаясь регламентного анализа, что исключает построение неверных и «тяжелых» планов запросов СУБД.
Важно обратить внимание на то, включена ли на сервере постоянная отладка. Запуск сервера приложений 1С с ключом -debug создает дополнительную нагрузку на рабочие процессы rphost, так как сервер вынужден непрерывно транслировать отладочную информацию. Если в данный момент разработка не ведется, отключите этот режим в параметрах службы 1С.
Релиз платформы 8.3.13 уже морально устарел. В старых версиях платформы содержатся утечки оперативной памяти при работе с динамическими списками управляемых форм. Переход на более современные и проверенные временем релизы (например, из веток 8.3.21 или 8.3.22) обеспечит стабильную утилизацию ресурсов сервера, исправит ошибки кэширования метаданных и ускорит общую работу интерфейса.
Подводя итог, отметим: залог быстрой работы 1С на PostgreSQL — это не разовые технические манипуляции, а комплексный подход, включающий оптимизацию интерфейсных механизмов, перевод торгового оборудования на производительные протоколы связи и тонкую регулярную настройку СУБД.