При работе с конфигурацией 1С:Зарплата и Управление Персоналом КОРП 3.1 пользователи часто сталкиваются с проблемой зависания "живого поиска" в полях выбора, например, при подборе сотрудника. Эта проблема особенно заметна при вводе определенных символов и работе пользователей с ограниченными правами (RLS). Давайте подробно разберем, почему возникает такое поведение и какие шаги можно предпринять для диагностики и устранения зависаний.
Анализ проблемы: симптомы и первоначальные попытки диагностики
Мы видим, что проблема проявляется избирательно. Пользователь сообщает, что клиент 1С намертво зависает при вводе определенных символов, таких как «с» или «в», в поле «Сотрудник». При этом ввод других символов, например «щ» или «ю», работает нормально, выдавая выпадающий список. Также отмечается, что быстрый ввод двух символов, например «со» или «вм», также проходит без проблем. Это указывает на то, что проблема, вероятно, связана с большим объемом выборки данных.
Давайте систематизируем ключевые наблюдения и действия, предпринятые автором темы:
Избирательность зависания по символам: Зависание происходит при вводе символов, которые, вероятно, приводят к очень большой первоначальной выборке данных (например, "с" или "в" могут начинать фамилии большого количества сотрудников).
Зависимость от документов: Проблема возникает не во всех документах. Например, в документе «Изменение условий исполнительного листа» зависает, а в «Исполнительный лист» – нет. Это может указывать на различия в запросах или используемых регистрах/справочниках.
Влияние RLS: Пользователи с полными правами не сталкиваются с проблемой, а отключение «Групп доступа» в настройках «Настройка пользователей и прав» устраняет зависание у всех. Это является критически важным наблюдением, указывающим на прямую связь проблемы с ограничениями на уровне записей (RLS).
Неэффективность стандартных мер: Чистка кеша на сервере, очистка и обновление индексов полнотекстового поиска (ПП) не помогли. Отключение и даже удаление каталога полнотекстового поиска также не устранило проблему. Это подтверждает, что корень проблемы лежит глубже, чем кэширование или ПП.
Зависимость от версии платформы: Зависания начали проявляться с определенной версии платформы 8.3.24.1758 и продолжаются на более новых, включая 8.3.25.1501, 8.3.25.1520, 8.3.26.1498, 8.3.26.1521. При этом на версиях 8.3.23.1782 и 8.3.24.1548 проблемы не было. Это указывает на возможные изменения в работе платформы с запросами или RLS, которые были внесены в этих версиях.
СУБД: Используется PostgreSQL. Это важно для анализа планов запросов.
На основе этих данных, мы можем сделать вывод, что основной причиной зависания, скорее всего, является неоптимальная работа запросов к базе данных, генерируемых платформой 1С при активном RLS, особенно на определенных версиях платформы и при больших объемах данных.
Основные причины зависания живого поиска с учетом RLS и платформы
Давайте рассмотрим подробнее факторы, которые могут приводить к таким проблемам:
Влияние RLS на производительность запросов
Ограничение доступа на уровне записей (RLS) – это мощный, но часто ресурсоемкий механизм. Когда активен RLS, платформа 1С добавляет в генерируемые SQL-запросы дополнительные условия, которые фильтруют данные, доступные текущему пользователю. Эти условия могут существенно усложнить запрос, увеличивая время его выполнения, особенно на больших объемах данных. Мы выяснили, что:
Применение RLS может приводить к построению неоптимальных планов запросов в СУБД.
Если у пользователя настроено несколько ролей с RLS, условия всех RLS могут добавляться в запрос с использованием логического оператора «ИЛИ». Это еще сильнее ухудшает производительность. В таких случаях мы рекомендуем создавать «смешанные» роли с объединенным RLS, чтобы избежать множественных «ИЛИ».
Начиная с версии 8.3.18 платформы 1С появился механизм оптимизации RLS, который может заменять подзапросы, не зависящие от защищаемой таблицы, на результат их работы, кешируемый в оперативной памяти. Однако его эффективность может различаться в зависимости от СУБД (PostgreSQL в нашем случае) и конкретной версии платформы.
В конфигурациях на базе БСП (Библиотека стандартных подсистем), начиная с редакции 3, реализован «производительный режим RLS». В этом режиме расчет прав происходит предварительно и записывается в специальные таблицы, а в итоговый запрос попадают только ключи доступа. Этот подход позволяет достичь высокой производительности запросов с RLS. Мы настоятельно рекомендуем проверить, поддерживает ли ваша версия ЗУП КОРП этот режим и активирован ли он.
Особенности платформ 1С и их влияние
Мы видим, что проблема возникла после обновления платформы 1С. Это частая ситуация:
Версии платформы 1С 8.3, как правило, демонстрируют снижение производительности на одних и тех же ресурсах с каждой новой версией (за исключением некоторых релизов). Это связано с растущими требованиями к аппаратной составляющей и изменениями в механизмах работы.
Возможно, в новых версиях платформы были изменены алгоритмы генерации запросов, связанные с RLS, или оптимизации, которые не всегда корректно работают с PostgreSQL или конкретной структурой данных.
Проблемы с запросами и их планами выполнения
Давайте углубимся в механизм выполнения запросов:
Неактуальная статистика в СУБД может привести к неправильной стоимостной оценке операций в запросе и к неоптимальному плану выполнения запроса. Это включает некорректное использование индексов и видов соединений.
Ограничения, накладываемые в шаблоне RLS, могут приводить к большому количеству соединений между таблицами, делая запросы "монструозными" и занимающими тысячи строк кода. Это значительно увеличивает время на поиск оптимального плана запроса СУБД.
Использование виртуальных таблиц в языке запросов 1С:Предприятия может приводить к разворачиванию их в подзапросы на уровне SQL. Это также может привести к выбору неоптимального плана. Мы рекомендуем выносить обращение к виртуальной таблице в отдельный запрос с сохранением результатов во временной таблице, если это возможно.
Оптимизация базы данных
Не забываем о базовых мерах по поддержанию производительности:
Индексы: Проведение аудита используемых индексов, удаление редко применяемых или дублирующихся, а также создание необходимых индексов для часто запрашиваемых данных может значительно улучшить производительность. Особенно это касается полей, по которым идет фильтрация в RLS.
Регламентные и фоновые задания: Избыток фоновых заданий, таких как обновление курса валют или классификаторов, может отбирать ресурсы и замедлять работу. Мы рекомендуем отключать ненужные задания или настраивать их выполнение вне рабочего времени.
Аппаратное обеспечение
Производительность напрямую зависит от "железа":
Проблема может быть связана с недостаточной мощностью оборудования, использованием HDD-дисков вместо SSD, медленным дисковым вводом-выводом, или низкой тактовой частотой процессора. Мы настоятельно рекомендуем использовать SSD (NVMe для сервера), увеличивать объем оперативной памяти (минимум 8-16 ГБ для клиентских машин, значительно больше для сервера), и процессоры с высокой тактовой частотой (минимум 2.4 ГГц).
Сетевое подключение: Нестабильное интернет-соединение или использование Wi-Fi может вызывать замедления. Желательно использовать проводное подключение для пользователей 1С.
Пошаговый план диагностики и решения проблемы
Для эффективного решения проблемы зависания живого поиска мы предлагаем комплексный подход, начиная с детальной диагностики и заканчивая оптимизацией:
Воспроизведение и локализация проблемы
Мы должны четко воспроизвести проблему. Зафиксируйте:
Точную последовательность действий пользователя, приводящую к зависанию.
Конкретные документы и поля, в которых происходит зависание.
Символы, которые вызывают проблему.
Роли пользователей, у которых возникает проблема.
Анализ влияния RLS
Поскольку проблема напрямую связана с RLS, это наш главный приоритет:
Проверка настройки «Группы доступа»: Мы уже знаем, что отключение «Групп доступа» (в меню Настройка пользователей и прав) устраняет проблему. Это подтверждает, что RLS является причиной.
Производительный режим RLS: Если ваша конфигурация ЗУП КОРП 3.1 основана на БСП 3 (или более новой), проверьте и активируйте «производительный режим RLS». Мы можем найти эту настройку в разделе
Администрирование -> Настройка пользователей и прав -> Группы доступа -> Производительный режим RLS
. Активация этого режима может кардинально улучшить ситуацию.
Аудит шаблонов RLS: Проанализируйте шаблоны RLS, которые применяются к справочнику «Сотрудники» или регистрам, связанным с сотрудниками, в контексте проблемных документов. Возможно, шаблоны слишком сложны или содержат избыточные соединения. Мы можем рассмотреть возможность их упрощения или переработки.
Объединение ролей: Если пользователь имеет несколько ролей, которые накладывают RLS на одни и те же данные, мы рекомендуем создать новую роль, которая объединяет все необходимые ограничения в одном шаблоне RLS, избегая использования множественных «ИЛИ».
Анализ запросов и планов выполнения в PostgreSQL
Поскольку СУБД у нас PostgreSQL, мы сосредоточимся на инструментах для этой системы:
Получение запроса: Когда проблема воспроизводится, нам необходимо получить полный текст SQL-запроса, который выполняется в PostgreSQL. Для этого мы можем использовать средства мониторинга PostgreSQL или Технологический журнал 1С (см. ниже).
Получение плана запроса: После получения запроса, мы должны выполнить его в консоли PostgreSQL с использованием команды EXPLAIN ANALYZE. Например:
EXPLAIN ANALYZE
SELECT
T1.Field1,
T2.Field2
FROM
Table1 AS T1
JOIN
Table2 AS T2 ON T1.Ref = T2.Ref
WHERE
T1._RLSVALUE_0RRef = ...
Мы внимательно анализируем полученный план запроса. Нас интересуют:
Типы соединений (Join Types): Ищем Hash Join, Merge Join, Nested Loop Join. Nested Loop Join на больших таблицах без подходящих индексов может быть очень медленным.
Использование индексов: Проверяем, используются ли индексы для фильтрации и соединений (Index Scan). Если вместо Index Scan видим Seq Scan (последовательное сканирование) на больших таблицах, это указывает на отсутствие или неэффективность индекса.
Стоимость операций (Cost): Оцениваем общую стоимость запроса и стоимость отдельных этапов.
Количество возвращаемых строк (Rows): Сравниваем ожидаемое и реальное количество строк.
Время выполнения (Actual Time): Анализируем время, затраченное на каждый этап.
Идентификация "тяжелых" условий: В запросе, который приходит из 1С, мы будем искать условия, добавленные RLS (например, WHERE T13._RLSVALUE_0RRef = ...). Мы постараемся понять, почему эти условия приводят к такому неоптимальному плану.
Оптимизация СУБД (PostgreSQL)
Мы проводим следующие работы по оптимизации PostgreSQL:
Обновление статистики: Мы регулярно обновляем статистику по таблицам базы данных. В PostgreSQL для этого используются команды ANALYZE или VACUUM ANALYZE. Это помогает оптимизатору запросов строить более эффективные планы.
Индексирование: Мы тщательно проверяем индексы. На основе анализа планов запросов создаем необходимые индексы для полей, участвующих в условиях RLS, в условиях WHERE, и в полях, по которым происходит соединение таблиц (JOIN). Мы также удаляем дублирующиеся или неиспользуемые индексы, которые могут замедлять операции записи.
Очистка и обслуживание базы данных: Мы регулярно выполняем регламентные работы по очистке базы данных (VACUUM FULL, если требуется, но с осторожностью, так как блокирует таблицы). Мы также можем рассмотреть архивирование старых данных или свертку информационной базы для уменьшения объема данных.
Настройки PostgreSQL: Мы проверяем параметры конфигурации PostgreSQL (например, work_mem, shared_buffers, maintenance_work_mem) и корректируем их в соответствии с рекомендациями 1С и имеющимися аппаратными ресурсами.
Проверка и обновление версии платформы 1С
Мы выяснили, что проблема зависит от версии платформы:
Если проблема возникла после обновления платформы, мы можем попробовать откатиться до последней стабильной версии, на которой проблема не проявлялась (в данном случае 8.3.24.1548). Однако это не всегда возможно, если новая версия конфигурации требует более новой платформы.
Мы также проверяем наличие новых релизов платформы, так как 1С регулярно выпускает обновления с исправлениями ошибок и улучшениями производительности. Возможно, в одном из последних релизов уже исправлена проблема, влияющая на RLS или работу с PostgreSQL.
Анализ аппаратных ресурсов
Мы проверяем:
Дисковая подсистема: Убеждаемся, что на сервере используются SSD-диски (предпочтительно NVMe) с достаточной скоростью ввода-вывода. Медленные диски являются частой причиной низкой производительности 1С.
Оперативная память: Проверяем объем ОЗУ на сервере 1С и сервере СУБД. Недостаток памяти приводит к активному свопингу и значительному замедлению.
Процессор: Проверяем загрузку процессора во время зависания. Процессоры с высокой тактовой частотой предпочтительнее для 1С.
Отключение полнотекстового поиска
Хотя автор темы уже пробовал это, для полноты диагностики мы должны убедиться, что полнотекстовый поиск (ПП) не является причиной:
Очищаем и удаляем каталог индексов полнотекстового поиска.
Проверяем работу "живого поиска".
Мониторинг фоновых заданий
Мы убеждаемся, что избыток фоновых заданий не отбирает ресурсы сервера в момент работы пользователей:
Проверяем список активных и запланированных фоновых заданий.
Отключаем или переносим на нерабочее время те задания, которые не являются критически важными.
Обновление конфигурации и платформы
Мы следим за регулярными обновлениями:
Регулярно обновляем конфигурацию ЗУП КОРП 3.1 до последних версий, так как разработчики 1С постоянно вносят исправления и оптимизации.
Обновляем платформу 1С до рекомендованных (или последних стабильных) версий, предварительно проведя тестирование на тестовой базе.
Использование технологического журнала 1С
Технологический журнал является мощным инструментом для детальной диагностики:
Настраиваем технологический журнал для записи событий DBMSSQL (или DBPOSTGR для PostgreSQL), CALL, SCALL, TTIMEOUT, EXCP.
Воспроизводим проблему и анализируем записи журнала. Нас интересуют долгие запросы к базе данных, клиентские вызовы, ожидания на блокировках и любые исключения.
Технологический журнал позволяет нам получить полный текст SQL-запроса, который выполняется платформой 1С, что критически важно для дальнейшего анализа в PostgreSQL.
Проверка на известные ошибки
Иногда проблема уже известна и задокументирована:
Мы проверяем сайт технической поддержки 1С (bugs.1c.ru) на наличие зарегистрированных ошибок, похожих на нашу проблему (например, ошибка 00-00701771, связанная с зависанием при вводе адреса сотрудника).
Если ошибка известна, мы можем узнать ее статус и в какой версии платформы или конфигурации она была исправлена.
Важные рекомендации
Для обеспечения стабильной и высокопроизводительной работы 1С:ЗУП КОРП 3.1 мы настоятельно рекомендуем следующее:
Разделение ролей сервера: Для крупных систем мы рекомендуем разделять роли сервера. Отдельный сервер для базы данных (PostgreSQL), отдельный для сервера приложений 1С, терминальный сервер для пользователей и отдельная машина для фоновых задач. Это позволяет эффективно распределять нагрузку и ресурсы.
Оборудование: Мы используем исключительно SSD-диски (предпочтительно NVMe) для сервера СУБД и сервера 1С. Увеличиваем объем оперативной памяти до достаточного уровня для кэширования данных в СУБД и для рабочих процессов 1С. Выбираем процессоры с высокой тактовой частотой.
Регулярное обслуживание ИБ: Мы внедряем регулярные процедуры по обслуживанию информационной базы: очистка, обновление статистики, реиндексация. Также рассматриваем возможность свертки или архивирования старых данных, чтобы уменьшить общий объем рабочей базы.
Сетевое подключение: Мы обеспечиваем стабильное и быстрое проводное сетевое подключение для всех рабочих мест пользователей 1С и между серверами.
Комплексное применение этих методов диагностики и оптимизации поможет нам выявить истинные причины зависания живого поиска и разработать эффективное решение для вашей системы 1С:ЗУП КОРП 3.1.