После проведения масштабных обновлений в решениях на базе 1С, таких как 1С:Комплексная автоматизация (2.5.8.268) в связке с CRM 3 (3.1.24.7), технические специалисты часто сталкиваются с деградацией производительности. Одной из наиболее острых проблем является критическое замедление открытия справочника Партнеры (он же Клиенты). Ситуация, когда форма открывается 3 минуты вместо привычных 5 секунд, требует немедленного вмешательства.
В данной статье мы разберем, почему стандартные методы очистки кэша могут не помогать, как настройки динамического списка влияют на SQL-запросы и каким образом восстановить работоспособность системы для всех пользователей. Мы проанализируем ситуацию совместно, шаг за шагом проходя путь от диагностики до окончательного решения.
Рассмотрим симптомы проблемы. Основная аномалия заключается в том, что замедление проявляется выборочно: у пользователей с полными правами справочник может летать, в то время как пользователи с ограниченными правами тратят минуты на ожидание. Однако, как показывает практика, даже временное назначение пользователю роли ПолныеПрава не всегда исправляет ситуацию «здесь и сейчас».
Выясним причины такого поведения. Проанализируем несколько важных факторов:
Партнеры построена на динамическом списке. Это сложный механизм, который генерирует SQL-запрос на лету, учитывая настройки пользователя: отборы, сортировки, группировки и условное оформление.Часто программисты замечают странную вещь: если скопировать текст запроса из динамического списка и выполнить его в консоли запросов или внешнем отчете под тем же пользователем, данные выводятся мгновенно. Почему же форма списка тормозит?
Проанализируем технологические различия:
Во-первых, динамический список запрашивает данные порциями (используя TOP в SQL-запросах). Чтобы корректно отобразить порцию данных, SQL-сервер должен построить план выполнения с учетом сортировки. Если в настройках пользователя установлена сортировка по неиндексированному полю или по сложному выражению, оптимизатор СУБД может выбрать неэффективный план.
Во-вторых, в динамическом списке активно работает механизм ДинамическоеСчитываниеДанных. При наличии сложных ограничений доступа (RLS) запрос обрастает многочисленными соединениями (JOIN) с таблицами прав. В режиме «Производительный» эти соединения идут к таблицам ключей доступа, что под нагрузкой может приводить к деградации производительности именно при постраничном выводе.
Одной из главных причин, почему стандартная кнопка «Очистить настройки» в интерфейсе не помогает, является структура хранения данных в 1С. Настройки форм сохраняются в системной таблице SystemSettingsStorage. При обновлении метаданных (особенно в тяжелых конфигурациях типа КА + CRM) структура объектов меняется. Старые настройки, сохраненные для конкретного пользователя, могут содержать ссылки на удаленные колонки, измененные типы данных или специфические условия оформления, которые визуально не отображаются, но продолжают участвовать в компоновке запроса.
Рассмотрим, как программно можно проверить наличие таких настроек или попытаться их очистить. Хотя ручное удаление записей из системных таблиц СУБД запрещено, мы можем использовать методы платформы.
Пример кода для программной очистки настроек конкретной формы:
// Очистка настроек конкретной формы списка для пользователя
КлючОбъекта = "Справочник.Партнеры.Форма.ФормаСписка/НастройкиПользователя";
Пользователь = "ИмяПользователя";
ХранилищеСистемныхНастроек.Удалить(КлючОбъекта, , Пользователь);
// Также стоит очистить настройки компоновщика данных
КлючКомпоновщика = "Справочник.Партнеры.Форма.ФормаСписка/НастройкиКомпоновщика";
ХранилищеСистемныхНастроек.Удалить(КлючКомпоновщика, , Пользователь);
Как выяснилось в ходе обсуждения на форуме, наиболее эффективным и быстрым способом исправления является копирование настроек формы от пользователя, у которого справочник открывается быстро (например, от только что созданного тестового пользователя), к проблемному пользователю.
Почему это работает? Копирование настроек на уровне системы полностью перезаписывает структуру данных в хранилище, заменяя «битые» или неоптимальные настройки корректными. Это эффективнее простой очистки, так как при очистке система может попытаться восстановить настройки из кэша или использовать значения по умолчанию, которые также могут быть повреждены.
Выполним следующие действия для исправления:
Партнеры.Если копирование настроек помогло лишь частично, необходимо проверить состояние механизмов ограничения доступа. В режиме «Производительный» крайне важно, чтобы все ключи доступа были актуальны.
Проанализируем выполнение регламентных заданий. Перейдем в список регламентных и фоновых заданий и найдем:
Заполнение данных для ограничения доступаОбновление ключей доступаЕсли эти задания зависли или завершились с ошибкой, пользователи с ограниченными правами будут сталкиваться с тормозами. Для принудительного обновления ключей по конкретному справочнику можно воспользоваться типовой обработкой «Обновление доступа на уровне записей» (доступна в составе БСП в разделе «Обслуживание»).
Рассмотрим пример того, как можно инициировать пересчет прав для объекта программно (для администраторов):
// Инициация обновления ключей доступа для справочника Партнеры
ПараметрыОбновления = УправлениеДоступомСлужебный.ПараметрыОбновленияДоступа();
ПараметрыОбновления.СписокСписков = Новый Массив;
ПараметрыОбновления.СписокСписков.Добавить(Метаданные.Справочники.Партнеры);
УправлениеДоступомСлужебный.ОбновитьДоступ(ПараметрыОбновления);
Подводя итог, можно сказать, что проблема долгого открытия справочника Партнеры после обновления в большинстве случаев вызвана конфликтом старых пользовательских настроек с новой структурой метаданных и механизмами RLS.
Ключевые выводы:
Партнеры, проиндексированы и корректно отображаются в динамическом списке.Следование этим шагам позволит вам вернуть комфортную скорость работы пользователям и избежать длительных простоев при работе с клиентской базой.