На протяжении нескольких недель пользователи ЛЭРС учёт нашей компании жалуются на значительно увеличение времени при подгрузки информации в ЛЭРС учёт. Это касается абсолютно всех действий: открыть свойство точки, объекта учёта, загрузка списка Работ, точек учёта, объектов учёта…
Для установления причин зависания я обратился к сотрудникам компании которая осуществляет сопровождение ЛЭРС учёт (на их серверах крутиться ЛЭРС учёт), с просьбой добавить процессоров, уж больно зависает ЛЭРС учёт. (к примеру сегодня одновременно загружался список точек учёта и справочник Оборудования. Справочник оборудования так и не загрузился…)
Далее привожу ответ специалистов осуществляющих сопровождение ЛЭРС учёт:
Доброго всем утра! снял трассу с процесса который максимально висит на сервере (запрос на - подгружаются датчики). В итоге выявил селект который выполняется очень долго. Провел анализ плана запроса и итоги следующие:
Вот сам запрос
а вот его план
в блоке плана где 41% потрачено времени вот такая картина
проблема в том что сначала он оптимально сопоставляет таблицу аккаунтов и нотификейшн, а потом пытается их сопоставить с таблицей Cotingency не совсем оптимально поскольку данные по которым он сопоставляет её не сортированы
09:21
иными словами Вам нужно передать разработчику следующее
09:22
При объеденении таблиц по полю IncidentId используется несортированный набор данных поскольку отдельного индекса по этому полю нет в таблице Notification. Эта связка выполняется во тут.
09:23
INNER JOIN [Contingency] AS [c] ON [n].[IncidentId] = [c].[Id]
09:23
Что бы сервер построил более оптимальный план запроса возможно на таблице Notification нужно создать дополнительный индекс по полю IncidentId
09:25
Естественно разработчикам это нужно будет протестировать на производительность
К примеру рассмотрим (не обязательно именно так): Желательно добавить это “проблемное” поле в первичный индекс второй строчкой, что бы результат выбора по первому полю выдавался вместе с IncidentId уже сортированным и в последствии связка проходила бы на много быстрее.
Есть ещё один файл который не крепиться к сообщению.
От себя могу сказать, что зависание системы Очень сильно осложняет нам работу, Прошу Вас внимательно отнестись к данному вопросу.
Спасибо за информацию, но делать кластерный индекс для уведомлений из Id и IncidentId не совсем правильно. Уведомления есть не только для нештатных ситуаций, но и для других типов, и НС у них будет null. Конкретную проблему мы, может, и решим, но это затронет и другие уведомления, например, по работам. И каким образом понять сходу сложною.
Отмечу, что проблема ещё и в количестве уведомлений. Есть подозрение, что у пользователей сейчас десятки если не сотни тысяч уведомлений по нештатным ситуациям, которые при загрузке приводят к такому эффекту.
Возможно, вам стоит настроить для пользователей уведомления по НС таким образом, чтобы они не отправлялись тем, кому эти уведомления не нужны. Или ограничить список типов НС или объектов, чтобы уведомления формировались только по действительно важным объектам.
И ещё, если есть возможность, дайте нам доступ к системе, чтобы мы могли к ней подключиться и выполнить несколько запросов, чтобы проверить есть ли другие места, в которых требуется внимание к производительности.
Перед этим в системных параметрах включите флажок “Разрешить просмотр результатов профилирования” на вкладке “Безопасность”. После проверки мы вам напишем, чтобы вы могли деактивировать учётную запись и снять этот флажок. Можно отправить доступ мне в личку, или на support@lers.ru
Какого уровня доступ вам нужен?
Собственно, как видно из вашего скриншота, данные настройки относятся к учетной записи, из чего следует, а значит их можно внести единожды в любом экземпляре Рабочего места оператора из под пользователя, обладающего соответствующими правами на изменение учетных записей, лучше всего системной учетной записи администратора.
Нам нужны параметры доступа к вашему Серверу ЛЭРС УЧЕТ, чтобы мы могли подключиться к нему из своего Рабочего места оператора. То есть адрес и порт Сервера, логин и пароль.
Единственное соответствующий специалист уходит в отпуск, поэтому к рассмотрению данной проблемы мы сможем приступить не раньше чем через три недели. Вы можете предоставить доступ по прошествии этого времени.
Добрый день!
Не совсем так. Это настройка для учётной записи, её можно сделать один раз через веб, или через АРМ оператора. На всех остальных АРМах будут применяться такие же параметры уведомлений.
Кроме того, для этого есть групповая операция, которая позволит убрать уведомления сразу у всех учётных записей. Для того, чтобы её запустить, на списке учётных записей выберите нужные флажками и нажмите кнопку “Редактировать”. В открывшемся окне выберите “Настроить параметры уведомлений”.
Так же, в системных параметрах на закладке “Обслуживание базы данных” перейдите на вкладку “Прочее” и ограничьте срок хранения уведомлений, например, 1 месяцем. Уведомления старше этого срока, как мне кажется, смысла несут мало.
Это позволит вам сильно уменьшить размер этой таблицы и предотвратит дальнейший бесконтрольный рост.