Использование проекта "Анализатор" для анализа SQL-запросов по логам отладочной версии ТБ.Корпорации

Задача

Проект «Анализатор» предназначен для того, чтобы по собранным отладочной версией ТБ.Корпорации логам можно было собрать статистику выполнения запросов, ранжировать их по частоте и времени исполнения и на основе этой информации заниматься оптимизацией системы.

Сбор логов

Логи SQL-запросов, выдаваемых отладочной версией ТБК, как и остальные логи записываются в текстовый файл в каталог TEMP Windows-а (более подробно про правило сбора лог файлов можно прочитать тут).

Принцип анализа

Мы предположили, что запросы можно разделить на классы, отличающиеся только конкретныим значениями фильтров. С помощью утилиты tblog2jur.exe, входящей в состав проекта, в SQL- запросах конкретные значения DocID, дат и прочих константных выражений заменяются на маски, после чего одинаковые запросы агрегируются. В результате получается аналитический справочник, содержащий классы запросов, и файлы в формате текстового журнала ТБК, для каждого SQL-запроса генерирующий проводку, оборотом в которой является длительность выполнения запроса, в привязке к элементу аналитического справочника - классу запроса. После этого можно использовать стандартный генератор отчетов ТБК для получения различных аналитических отчетов.

Можно также предположить, что запросы одного класса выполняются одинаковое время. На практике это не так - расхождения могут быть вызваны загрузкой сервера, внутренними его алгоритмами, действиями других пользователей в это время. Однако в целом данная тенденция имеется, и основываясь на ней, можно предпринимать меры по оптимизации.

Как получить из логов отчеты

Сначала создайте на проекте Анализатор информационную базу. Проект носит внутренний, вспомогательный характер, поэтому мы не стремились к его интерфейсной красоте. Просто войдите в сессию под именем Администратор с полными правами. Через список бланков (Alt-B) откройте бланк «БланкИмпорт». С его помощью можно сконвертировать лог (файл *.lst) в аналитический справочник и журнал ТБК. Для больших логов процесс конвертации может занять длительное время.

Если в лог выведены столбцы с именами модулей и/или именами процессов, то при импорте нужно установить соответствующие опции, чтобы конвертор логов проигнорировал эти стоблцы.

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

Основные отчеты и информация в них

Вызовите список отчетов (Alt-Q). В проекте Анализатор предусмотренные базовые, наболее часто используемые виды отчетов:

  1. отчет «Все задержки». Отражает распределение времени между выполнением запросов, завершениями транзакций и и разного рода блокировками. Строка «СчЗапрос» показывает общее время и количество выполненных запросов; «СчCommit» - общее время и количество вызовов оператора COMMIT (завершение транзакции); «СчEnter» - общее время и количество блокировок, когда запрос на чтение ожидает завершение запроса на запись и наоборот. Это наиболее важная цифра - как правило, резкое замедление работы системы объясняется ростом числа блокировок. Количество блокировок можно уточнить отчетом «Аналитическая ведомость счета» по параметру режим. В этом отчете «1» означает блокировку на чтение («читатель ждет писателя»), 2 - блокировка на запись («писатель ждет читателя»), а 3 - эксклюзивный режим доступа, применяемый в различных случаях.
  2. отчет «ПоЗапросам\ПоТипам». Отображает классы запросов с указанием их количества и суммарного времени исполнения. Если отсортировать его либо по количеству запросов, либо по длительности, можно составить картину загрузки SQL-сервера. Очевидно, что в первую очередь оптимизации подлежат самые частые запросы и запросы, занимающее наобольшее место в общем времени исполнения. С помощью стандартного механизма уточнения отчетов данный отчет можно уточнить отчетом по проводкам и получить уже список конкретных запросов, сформировавших уточняемую длительность, с указанием момента их выдачи и потока, их выдавшего.
  3. отчет «ПоЗапросам\ПоДлительности». Позволяет оценить долю медленных запросов в общем времени исполнения запросов. Чем больше медленных запросов, тем, естественно, медленнее работает система, но самое главное - при этом возрастает вероятность блокировок, которые в свою очередь замедляют другие запросы, и замедление нарастает как снежный ком.

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

Некоторые дополнительные замечания

На основании опыта использования проекта Анализатор и оптимизации запросов с его помощью можем посоветовать следующее:

имейте в виду, что в логах отражается только время выполнения запроса. После собственно отбора данных SQL-сервером делается их выбор библиотеками ADO, который также занимает время, в некоторых случаях в разы превосходящее время запроса. Мы постараемся доработать анализатор таким образом, чтобы он учитывал это время, однако при анализе запросов надо понимать, что быстрый запрос, под который попадает много записей, может в сумме с выборкой данных исполняться медленно;

обращайте внимание на префиксы SC и CC перед текстом запроса. SC означает использование серверного курсора, а CC - клиентского. В первом случае навигация по данным происходит внутри SQL-сервера, во втором - внутри сервера данных ТБК. Использование серверного курсора дает выигрыш, если под фильтр запроса попадает много записей. В данный момент явное включение серверного курсора производится установкой опции LargeResult в хинтах запроса, но мы рассматриваем возможность более частого их использования по умолчанию;

обращайте внимание на запросы типа «подзагрузка». Это запросы примерно такого вида:

SELECT [A37].[DocID],[A37].[КодФилиала],[A37].[УровеньКонфиденциальности],[A37].[ЭлементСБ], ..другие поля...
  FROM [Ресурс] A37 WITH (NOLOCK) WHERE [A37].[DocID] =?

Т.е. это запрос, загружающий много полей для одной-единственно записи по его DocID. Как правило, такие запросы появляются, если на сервере происходит обращение к полю уже полученной другим запросом записи, но в ходе первого запроса данное поле загружено не было. Часто от большинства подзагрузок можно избавиться, если точнее настраивать свойство LoadingFields запросов, а также аналогичные свойства в параметрических отчетах и реквизитах типа «Сервисная процедура». Можно также сократить число подзагрузок, увеличив кеш записей на клиентских места (меню «Сервис/Системные настройки», раздел «Картотеки», закладка «Записи»). Избавиться на 100% от подзагрузок не удастся, это в некотором роде естественное поведение системы, поэтому в первую очередь нужно контролировать массовые подзагрузки, выдаваемые подряд.

оптимизация системы на основе анализа логов требует репрезентативности информации. Мы предпочитаем оперировать логами за полный день работы предприятия, в редких случаях - за полдня. Поэтому, если поставлена задача комплексной оптимизации работы системы, то рекомендуется проводить анализ логов ежедневно. При этом сами логи можно сбрасывать на диск (записывать в файлы) чаще - несколько раз в день, поскольку они также занимают место в оперативной памяти и могуть быть довольно большими. После записи логов на диск очищайте отладочное окно.

 
studio/analyze_log.txt · Последние изменения: 2016/04/15 15:26 (внешнее изменение)
 
За исключением случаев, когда указано иное, содержимое этой вики предоставляется на условиях следующей лицензии:CC Attribution-Noncommercial-Share Alike 3.0 Unported
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki