← На главную

Многие пользователи 1С:Управление торговлей 11 сталкиваются с проблемой критически медленной работы режима подбора номенклатуры. Эта проблема может проявляться в различных сценариях: от банального торможения при прокрутке списка товаров до полного зависания программы или даже некорректного отображения имеющихся на складе позиций. Часто возникает ощущение, что даже на мощных компьютерах с современными процессорами, большим объемом оперативной памяти и SSD-дисками проблема сохраняется, что указывает на глубинные причины, связанные не только с аппаратной частью, но и с архитектурой самой конфигурации и базы данных.

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

1. Диагностика замедлений с помощью "Замера производительности"

Первым и наиболее важным шагом в решении любой проблемы производительности является точная диагностика. Если мы не знаем, где именно происходит "узкое место", наши попытки оптимизации могут быть бесполезны. В этом нам поможет встроенный в платформу 1С инструмент – "Замер производительности".

1. Запускаем замер: Прежде всего, нам необходимо запустить процесс замера производительности перед тем, как выполнять медленную операцию подбора номенклатуры. Это можно сделать через главное меню (обычно "Сервис" или "Все функции" -> "Стандартные" -> "Замер производительности").
2. Воспроизводим проблему: После активации замера, максимально точно воспроизводим сценарий, который вызывает торможение – открываем форму подбора, прокручиваем список, ищем товар и так далее.
3. Анализируем результаты: После завершения операции, останавливаем замер и анализируем полученные данные. Инструмент покажет нам, на каких фрагментах кода, в каких запросах и функциях было затрачено наибольшее количество времени.

Консоль запросов также является незаменимым помощником. Она позволяет отлаживать и оптимизировать запросы, показывая время выполнения каждого пакета. Если замер производительности указывает на конкретный запрос как на причину замедления, мы можем скопировать этот запрос в консоль, поэкспериментировать с его структурой, добавить индексы и оценить влияние изменений на скорость его выполнения.

2. Оптимизация запросов в динамических списках

Очень часто корень проблемы кроется в динамических списках, которые используются для отображения номенклатуры в форме подбора. Конфигурация 1С:УТ 11, как и многие другие современные конфигурации на управляемых формах, активно использует динамические списки, и их производительность напрямую зависит от сложности и оптимальности запросов, лежащих в их основе.

Рассмотрим подробнее возможные причины и пути решения:

1. Неоптимальные запросы: Разработчики 1С, как отмечено в обсуждении, иногда могут писать запросы, не стесняясь в ресурсах. Это приводит к тому, что запросы в динамических списках становятся слишком сложными, содержат множество соединений, подзапросов или обращений к виртуальным таблицам, что сильно нагружает СУБД. Особую проблему создают запросы, в которых некорректно используются индексы или применяются логические операции ИЛИ, которые могут обходить использование индексов.
2. Учет по характеристикам: Если в вашей базе включен учет по характеристикам, это дополнительно усложняет запросы к номенклатуре, так как система вынуждена подтягивать и анализировать данные из дополнительных регистров и справочников, связанных с характеристиками. Это может быть одной из причин, почему даже при наличии товара на складе, он не отображается в подборе или отображается с задержкой, как упоминалось в одном из сообщений.
3. Обращение к свойствам объектов через точку: Распространенной ошибкой в коде, приводящей к медленной работе, является обращение к свойствам объектов через точку (например, Номенклатура.ВидНоменклатуры.Наименование) внутри циклов или в запросах. Каждое такое обращение может вызывать отдельный неявный запрос к базе данных, многократно увеличивая нагрузку. Старайтесь избегать таких конструкций, предпочитая явные соединения таблиц в запросах.
4. Пользовательские группировки: Пользователи могут создавать свои собственные группировки в динамических списках. Хотя платформа предоставляет такую возможность, она не всегда может гарантировать оптимальную производительность, особенно если число записей превышает несколько сотен. Для больших списков рекомендуется ограничивать использование сложных группировок.
5. Переработка запросов: В случае, когда типовой подбор номенклатуры сильно тормозит (особенно при наличии десятков тысяч позиций), единственным эффективным решением может стать переработка запросов, лежащих в основе динамического списка. Опытный программист может проанализировать текущий запрос, выявить "узкие места" и оптимизировать его, а при необходимости — даже создать собственный механизм подбора товаров в документы, который будет работать значительно быстрее за счет упрощенной логики или использования временных таблиц.

3. Переход на клиент-серверный вариант работы

Тип развертывания базы 1С играет критическую роль в производительности, особенно при росте количества пользователей и объема данных. Если вы используете файловый режим работы (.dt файл), то это, по общему признанию, является серьезным ограничением для производительности, если в системе работает более 1-2 пользователей. В файловом режиме все операции с данными выполняются на клиентской машине, что приводит к значительному сетевому трафику и неэффективному использованию ресурсов.

Рассмотрим преимущества клиент-серверного варианта:

1. Распределение нагрузки: В клиент-серверном режиме (с использованием СУБД, такой как MS SQL Server или PostgreSQL) основные операции по обработке данных выполняются на сервере базы данных. Клиентские машины отправляют лишь небольшие команды, а сервер обрабатывает запросы и возвращает только необходимые результаты. Это значительно снижает нагрузку на сеть и клиентские компьютеры.
2. Эффективное использование ресурсов: Сервер СУБД может эффективно использовать свои аппаратные ресурсы (процессоры, оперативную память, быстрые диски) для оптимизации выполнения запросов и индексации данных. В то время как файловый режим, даже на мощном компьютере, может использовать лишь часть доступной оперативной памяти.
3. Рекомендации по ресурсам:
   • Оперативная память: Для комфортной работы 1С рекомендуется минимум 4 Гб ОЗУ на каждого пользователя, плюс 1 Гб на каждую используемую базу. На сервере СУБД требуется значительно больше памяти для кэширования данных.
   • Жесткие диски (IOPS): Критически важна скорость чтения-записи дисков (количество операций ввода-вывода в секунду, IOPS) на сервере СУБД. Рекомендуется разделять данные, логи и временные базы данных (tempdb) на разные быстрые диски (SSD, NVMe) или дисковые массивы.
   • Сеть: Стабильное и быстрое сетевое подключение между сервером 1С, сервером СУБД и рабочими местами является залогом высокой производительности. Нестабильность или низкая скорость сети могут создавать "тормоза", даже если серверы работают отлично.

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

4. Очистка настроек формы пользователя

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

Мы выяснили, что план запросов в СУБД для одной и той же операции подбора мог генерироваться по-разному. После очистки настроек формы подбора номенклатуры у проблемных пользователей, ситуация нормализовалась, и план запроса стал всегда одинаковым и оптимальным. Этот метод можно применить следующим образом:

1. Используем типовую обработку: В конфигурации 1С:УТ 11 существует типовая обработка Обработка.НастройкиПользователей. С помощью этой обработки мы можем получить доступ к сохраненным настройкам форм для конкретных пользователей и выборочно их очистить.
2. Встроенные средства: Также можно попробовать очистить настройки пользователя через стандартные средства 1С, например, через раздел "Персональные настройки" или "Настройки пользователя" в меню "Администрирование".

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

5. Общие рекомендации по оптимизации производительности

Помимо основных решений, мы рассмотрим ряд других факторов и методов, которые могут влиять на скорость работы подбора номенклатуры и системы 1С в целом.

5.1. Управление объемом базы данных

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

Решения:

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

5.2. Оптимизация RLS (Ограничение прав на уровне записей)

Механизм RLS (Record Level Security) позволяет гибко настраивать права доступа пользователей к данным, вплоть до отдельных записей. Однако, если RLS настроен избыточно сложно или неоптимально, особенно при большом количестве номенклатуры и высокой детализации прав, это может приводить к значительным задержкам. Каждое обращение к данным будет сопровождаться дополнительной проверкой прав, что увеличивает время выполнения запросов.

Решения:

1. Анализ и упрощение: Проанализируйте текущие настройки RLS. Возможно, некоторые ограничения избыточны и могут быть упрощены или даже удалены.
2. Оптимизация реализации: Если RLS реализован через запросы к регистрам сведений, убедитесь, что эти запросы оптимальны и используют индексы.

5.3. Регламентные и фоновые задания

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

Решения:

1. Перенос на нерабочее время: Перенесите трудоемкие регламентные задания на ночное время или в период минимальной активности пользователей.
2. Оптимизация заданий: Проверьте логику выполнения регламентных заданий. Возможно, некоторые из них могут быть оптимизированы для более быстрого выполнения.

5.4. Влияние антивирусного программного обеспечения

Антивирусное программное обеспечение, установленное на рабочих местах пользователей или на сервере 1С/СУБД, может быть причиной замедлений. Если антивирус активно сканирует файлы базы данных 1С, временные файлы или файлы программы 1С:Предприятие, это может создавать значительную дополнительную нагрузку.

Решения:

1. Исключения: Настройте исключения в антивирусном ПО для папок с базами данных 1С, папок с программными файлами платформы 1С и технологическими журналами.
2. Производительность: Убедитесь, что антивирус не создает избыточную нагрузку на дисковую подсистему.

5.5. Обновление платформы и конфигурации

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

Решения:

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

5.6. Переход с УТ 10.3 на УТ 11

Если проблема возникла после перехода с УТ 10.3 на УТ 11.1 (как в одном из случаев), важно понимать, что это не просто обновление, а переход на фактически новую систему с другой архитектурой (управляемые формы, клиент-серверная технология). УТ 11.x значительно более требовательна к ресурсам сервера и имеет более сложную для доработки клиент-серверную технологию. Это может потребовать не только оптимизации кода, но и обновления парка ПК, а также адаптации бизнес-процессов.

Заключение

Проблема медленной работы подбора номенклатуры в 1С:УТ 11, как мы выяснили, редко имеет одно-единственное решение. Чаще всего требуется комплексный подход, включающий в себя диагностику с помощью "Замера производительности", оптимизацию запросов в динамических списках, переход на более производительный клиент-серверный вариант работы, регулярную очистку настроек пользователя и общую настройку производительности системы. При необходимости, не стесняйтесь привлекать опытных программистов, которые помогут провести глубокий анализ и внести необходимые изменения в код конфигурации. Совместными усилиями мы сможем значительно ускорить работу подбора номенклатуры и сделать ее более комфортной для пользователей.