Зависание системы и медленная работа

Добрый день, Антон!

Причины возникновения проблемы могут быть самые разные. Для генерации решения нужно определить её источник (база данных, аппаратное обеспечение сервера или клиентские места). В момент возникновения замедлений проверить у всех ли пользователей это происходит одновременно. Если «да», то обратить внимание на сервер, в частности, на загрузку ЦП и оперативной памяти. Если там всё в порядке, тогда нужно моделировать ситуацию и в это время с помощью утилиты «SQL Server Profiler» пробовать отследить проблемные запросы к базе для возможности их оптимизации. Следующий этап – это проанализировать зависит ли замедление от пользователя, админ\не админ (играют ли роль права доступа). На скорость работы (время отклика системы), также, может влиять количество колонок, которые отображаются в реестре записей (желательно лишние спрятать), наличие сортировки по каким-то из полей реестра (убрать сортировку можно зажав Ctrl и кликнув по полю).

Со временем может быть нарушена структура индексов базы данных (создаются для ускорения выборки данных). Их можно перестроить при помощи скрипта Reindex.rar (во вложении). Рекомендации по выполнению скрипта – во вложении. После выполнения скрипта создаётся хранимая процедура «sp_reindex_all_tables». Её нужно запустить на выполнение. В зависимости от количества индексов, размера базы данных и ресурсов сервера выполнение данной процедуры может занять достаточно продолжительное время при этом нагружая сервер. В связи с этим, если вы будете пересоздавать индексы, рекомендую запускать процесс, когда пользователи не работают с системой. Перед этим обязательно создайте резервную копию базы данных.

Если у вас есть проектные решения стоит обратить внимание и на этот момент. Возможно есть нюансы реализации дополнительной логики.

Последние бинарные файлы версии 3.3.2.313. Для их получения Вы можете обратиться в службу поддержки.
Однако, не уверенна, что одно только обновление файлов решит проблему.
Разбираться с данной ситуацией нужно комплексно, так как причины могут быть самые разнообразные.

Добрый день Антон!!!

Алла сказала верно, что причины возникновения могут быть самые разные. Но раз вы пользуетесь Клиент-Серверным приложением, версии 3.3.2, то я бы обратил внимание в каких именно бизнес-процессах происходит зависание, в каких именно разделах происходит зависание, в каких именно деталях происходит зависание. И уже после этого стал анализировать в первую очередь SQL запросы, что работают в разделе, деталях, карточках редактирования в бизнес-процессах. ведь неправильно составленные и оптимизированный SQL запросы дают в первую очередь такой эффект. В бизнес-процессах я бы чтобы найти ошибку или зависание в первую очередь произвел бы оптимизацию, путем деления больших процессов на более мелкие, чтобы именно в каждой маленькой сущности искать уже проблемы. Если нужна помощь советом более подробно пишите, буду рад вам помочь.

Причины действительно могут быть разные, но в данной ситуации у нас следующие факты и на большинстве рабочих мест кейсы отрабатывают в два раза дольше:
При сравнении рабочего места быстрого и медленного был проведен следующий анализ:
- Запросы на сервере отрабатывают быстро
- Время обработки запросов на сервер в одних и тех же кейсах для разных рабочих мест примерно одинаковое и не зависит от конкретного времени (очень редко зависит от определенного времени в течении дня)
- Сервер мониторили - ЦП оперативки с большим запасом
- Для надежности кэш почистили на всех рабочих местах
- Проверяли под одним и тем же пользователем Terrasoft на разных рабочих местах, давали пользователю права локального админа на рабочее место, запускали Terrasoft от имени администратора.
- Проводили полную установку Terrasoft и пользовательскую.
- Рабочие места где происходит разница во времени не зависят от места расположения комнаты в офисе, сети и операционной системы (у нас либо Win 7 64 либо 32)
- Не зависит от железа компьютера, на более медленных машинках (на пример 4 гб, в место 8 Гб) наблюдались более длительное время выполнение, причем не зависело от количества запущенных в дополнении приложений.
- Самое главное, при всех сравнения и экспериментах время выполнения кейсов не менялось (на разных рабочих местах) например на одном 4 сек сохранение проекта, под другим 8 сек. И чтобы мы не делали значения там где медленее не менялось в лучшую сторону. Мы разбили даже код на куски и производили логирование по частям исполняемого кода, в результате мы не нашли конкретных проблемных мест в основном мы наблюдали пропорциональное возрастание времени исполнения кода на клиенте на разных рабочих местах, при этом сервер обрабатывал запросы одинаково.
- У нас проектное решение

Здравствуйте,

на ваш вопрос ответил в рамках обращения в службу поддержки.

А профайлер на sql сервере в самих запросах не помог выявить проблемные запросы с длительным выполнением?
Проблема то в коде скорее всего... либо тяжелые запросы, либо неаккуратные скрипты при сохранении записей, в любом случае это надо брать базу и тестировать.

Добрый день!
Проблема зависаний действительно есть и с ней я столкнулся опять совсем недавно.
Нужно было в карточке проставить связанные продажи. Попросили пользователей создавать продажи и потом выбирать их в карточке.
Значения для поля продажа в карточке фильтруются OnPrepareSelectWindow. Заполнить надо было около 800 карточек.

Так вот после 40-50 заполнений система зависала или вываливалась ошибка, не связанная с конкретным кодом. Анализ показал, что клиентское приложение так себя ведет когда начинает использовать память больше определенного значения. А занимаемая память увеличивается после открытия каждой карточки или датасета. И не освобождается.

Подчеркиваю. Проблема не с сервером, а именно на клиентских машинах. Самое смешное, что физической памяти на компах еще много в этот момент, но клиент выше определенного предела видимо использует ее некорректно. И это не зависит от x64. Я повторил такую же проблему у себя на ноуте, где x32.

Уважаемые разработчики! Можно ли это как то исправить? Это сильно мешает работать и портит впечатление от в целом неплохой системы. Могу попробовать помочь симулировать ситуацию на базовой конфигурации.

Здравствуйте, Виктор!

Повторюсь, но причины возникновения проблем с производительностью могут быть разнообразные и не факт, что проблема, о которой пишет автор поста, такая же, с которой столкнулись Вы.

Вероятно, Вы пользуетесь не самой последней версией приложения Terrasoft.

На сегодняшний день последней версией Terrasoft является версия 3.4.1.186.

Добрый день, Алла.
Мы как и автор темы используем конфигурацию версии 3.3.2. и насколько я знаю использовать клиента 3.4.1 несколько невозможно. Или я ошибаюсь?
Для 3.3.2. последние бинарники вчера получил.

"Гетманенко Виктор" написал:использовать клиента 3.4.1 несколько невозможно. Или я ошибаюсь?

Денежку за использование лицензий 3.4.1 заплатите и используйте просто новые бинарники, без перевода конфигурации на новую версию.

Про переполнение памяти на клиенте - либо проблема бинарников, либо что более вероятно криво написанный код в том месте, использование которого вызывает переполнение...

Здравствуйте, Виктор.

Как выше написал Александр, утечка памяти может происходит в коде, например, при открытии карточки редактирования мы создаем глобальный объект, который не уничтожаем по закрытию карточки редактирования.

В версии 3.4.1 не наблюдал утечки памяти.

"Александр Кудряшов" написал:без перевода конфигурации на новую версию

ну с 3.5 это точно не прокатит. А вот про 3.4 не проверял.

"Александр Кудряшов" написал:либо что более вероятно криво написанный код в том месте, использование которого вызывает переполнение

этот "криво написанный код" обычно является стандартной функцией scr_DB и называется AppendRecordInDataset

"Гетманенко Виктор" написал:AppendRecordInDataset

это безобидная функция добавления записи... и вызывается она в коробке вроде только из scr_Access функции AddAccessRecord... т.е добавление прав доступа.
Внутри у нее Append, Post - вот видимо они память и жрут... ну в любом случае тут надо предметно отладкой заниматься :)

Добрый день, Павел.

"Терещук Павел" написал:например, при открытии карточки редактирования мы создаем глобальный объект, который не уничтожаем по закрытию

Я пробовал уничтожать объекты. Эффекта нет. Возможно, конечно, неправильно это делаю.
Присваиваю объекту null и делаю delete для ActiveX объектов?

А какие ActiveX объекты используете в окне редактирования?

Добрый день, коллеги! Выявили одну, по нашим догадкам, из основных проблем. Проблема с сортировкой - стандартный функционал позволяет сортировать разделы, но в трейсе (преобразовав в запрос) четко видно, что основное время затрачивается на сортировку (например по типовому полю «дата начало» - 1 мин 30 сек (при этом мы закомментили из запроса большинство полей (иначе еще дольше) оставив - ID, Название , номер и дату старта). Без сортировки меньше секунды.
Подскажите, в чем может быть проблема сортировки?

Если при сортировке по полю происходит замедление, можно попробовать добавить в таблице БД индекс по этому полю.

На этих колонках есть индексы

Антон, судя по тексту запроса,дата начала — это не просто поле, она вычисляется отдельным подзапросом с достаточно сложным условием из EXISTS и NOT EXISTS. И при сортировке по ней запрос будет выполняться долго в любом случае, хоть его запустить из Terrasoft, хоть напрямую запустить этот код из Management Studio.

Если нужно понять узкие места в запросе, можно воспользоваться инструментами анализа плана выполнения запросов.

Если нужно по ней сортировать, есть смысл переделать логику, чтобы значения поля хранились в базе, а не вычислялись на ходу.