кейсы клиентов
Зависания при работе пользователей
Анамнез
Конфигурация Документооборот 2.1.
Пользователи стали обращаться с жалобами на произвольные зависания в работе. Попытки выяснить у пользователей, какие именно операции приводят к проблемам, не увенчались успехом.
Изначально было не очень понятно где может быть узкое место, поэтому для всех серверов был включен сбор счетчиков производительности, а для базы документооборота включили все показатели Монитора.
В том числе был включен показатель Долгий запрос со сбором планов.
Список показателей доступных для анализа базы
При анализе собранных данных выяснилось, что в базе отсутствуют ожидания на блокировках, оборудование не сильно загружено, но есть большое количество проблемных запросов без контекста.
Такие запросы составляли примерно половину (48.51%) от всех собранных запросов.
Список запросов без контекста
Текст запроса не имеет контекста, при этом начинается с SELECT TOP 45, это говорит о том, что, скорее всего, запрос был вызван из динамического списка.
Помимо этого в условиях запроса присутствует перечисление полей через OR с условием LIKE ? ESCAPE '/'.
В результате анализа выяснилось что пользователи запускают в формах списка поиск вводом с клавиатуры, который ищет по всем полям.
Условия указывают на поиск по всем колонкам в динамическом списке
Значения параметров поиска одинаковое, что также подтверждает версию о быстром поиске
Ситуация усугублялась использованием RLS, что делало текст запроса и план значительно больше и сложнее.
Значения параметров поиска одинаковое, что также подтверждает версию о быстром поиске
В результате дальнейшего анализа при использовании данных Active Monitor в Management Studio выяснилось, что пользователь не дожидался результата поиска. Спустя несколько секунд он нажимал ESC и запускал поиск заново, либо открывал новый сеанс 1С.
При этом на сервере СУБД тысячи секунд выполнялись запросы, результат которых был уже никому не нужен.
С помощью Монитора удалось найти точки возникновения долгих запросов т.к. момент начала запроса и имя пользователя были известны, далее с помощью журнала регистрации и текста запроса не составляло большого труда определить конкретный динамический список.
В итоге были доработаны формы проблемных списков, а именно запрещен поиск по всем колонкам сразу и убрана сортировка списка там, где в этом не было необходимости.
Теперь пользователи могут выполнять поиск только по определенной колонке.
После оптимизации ушли жалобы на долгий поиск в списках, при этом снизилась дисковая нагрузка на сервере баз данных, что положительно сказалось на скорости работы всей системы и отзывчивости СУБД.
Показатель "Долгий запрос", описанный в данном кейсе, доступен в бесплатной версии Монитора
Подпишитесь на наш канал в Telegram чтобы не пропускать новые материалы
Если вы хотите поделиться своим кейсом, напишите нам на support@1smonitor.ru