Ситуация, когда динамический список номенклатуры начинает «зависать» при скроллинге после обновления релиза конфигурации, знакома многим специалистам. Давайте вместе разберем, почему это происходит и как вернуть системе прежнюю скорость работы.
Прежде чем приступать к программной оптимизации, проанализируем ресурсы сервера. В обсуждаемом случае система работает в крайне жестких условиях: всего 4 ГБ оперативной памяти и бюджетный процессор AMD A6. При работе MS SQL Server в таких условиях критически важен объем RAM. Если памяти не хватает, операционная система начинает активно использовать файл подкачки (своп) на HDD.
Рассмотрим подробнее: когда процессы rphost и sqlserver постоянно обращаются к диску для обмена данными, процессор тратит колоссальные ресурсы не на вычисления, а на обработку операций ввода-вывода. В итоге даже простая прокрутка списка превращается в мучение, так как система постоянно «подгружает» данные с медленного жесткого диска.
Динамический список в 1С — это не статичная таблица, загруженная в память. При скроллинге платформа выполняет запросы к базе данных «на лету», чтобы получить порцию записей для текущей видимой области. Разберем основные причины, почему это стало работать медленно:
Ссылка.Владелец.Наименование или другие обращения к реквизитам через точку, при отображении каждой строки сервер 1С вынужден выполнять дополнительные соединения (JOIN) в базе данных.Давайте попробуем структурированно подойти к решению данной проблемы. Мы рекомендуем выполнить следующий план действий:
Рассмотрим настройки самого динамического списка. Чтобы скроллинг был плавным, старайтесь не выводить в него «тяжелые» поля. Важно: старайтесь использовать только примитивные типы данных, которые хранятся непосредственно в основной таблице объекта.
Если в списке отображаются поля, за которыми системе нужно «ходить» в другие таблицы, попробуйте временно их убрать и проверить скорость. Если тормоза исчезли — значит, проблема была именно в дополнительных соединениях.
Это действие является обязательным после любого обновления платформы или конфигурации. SQL Server должен понимать, как изменились данные. Выполните процедуру обновления статистики для всех таблиц базы данных. Это поможет оптимизатору запросов строить более быстрые планы выполнения.
Вы можете использовать следующий SQL-запрос в Management Studio:
-- Обновление статистики для всей базы
USE [ИмяВашейБазы];
EXEC sp_updatestats;
После выполнения этой команды SQL Server заново проанализирует индексы и распределение данных, что часто дает мгновенный прирост производительности.
Если программные методы не дают существенного результата, проанализируем «железо». При работе с MS SQL Server крайне рекомендуется перенести базу данных на SSD-накопитель. Даже если объем RAM остается ограниченным, скорость случайного чтения с SSD в десятки раз выше, чем с обычного HDD, что позволит избежать критических тормозов при своппинге.
Также проанализируйте загрузку процессора через Диспетчер задач во время скроллинга. Если загрузка одного ядра достигает 100%, это подтверждает, что SQL Server выполняет тяжелый запрос, который не оптимизирован или упирается в ограничения текущей редакции (например, SQLExpress).
Для исправления ситуации мы предлагаем двигаться по пути исключения лишней нагрузки на SQL:
Функциональные опции или RLS, которые «тяжелят» запросы.Технологический журнал для фиксации запросов, которые выполняются дольше всего при открытии и прокрутке списка.Работая сообща над этими пунктами, вы сможете добиться возвращения прежней скорости работы списка номенклатуры!