gifts2017

Простой способ определения узких мест конфигурации

Опубликовал Илья Фамилия (m191) в раздел Администрирование - Сервисные утилиты

В силу различных причин, информационная база 1С с которой работают законописатели, 3 программиста и около 200 пользователей, начала "тормозить". Изучив в интернете возможности различных способов поиска путей оптимизации, я изобрел собственный "велосипед", назвав его "методом идентификации запросов".
Основное назначение метода, это поиск неоптимальных запросов к MS SQL. Приложив немного усилий по модификации кода, мы получили инструмент позволяющий в любой момент ответить на вопрос: "что и когда тормозит?"

Суть проста: в каждый запрос 1С добавляем текстовое поле с идентификатором. Можно использовать строкового (например, КодИБ_ИдЗапроса) или для уменьшения объема генерируемых данных использовать числовые идентификаторы (необходимо иметь таблицу соответствий: код – описание запроса). Запрос с идентификатором будем называть помеченным запросом. Для удобства мониторинга, желательно идентификатор делать первым полем в запросе. При оптимизации «тяжелого» запроса рекомендую изменять идентификатор.

Это просто пример,

                З = Новый Запрос("ВЫБРАТЬ

                                 |            ""ЭтоНашИдентификаторЗапроса_версии1"" КАК Поле1,

                                 |            Номенклатура.Ссылка

                                 |ИЗ

                                 |            Справочник.Номенклатура КАК Номенклатура

                                 |ГДЕ

                                 |            Номенклатура.Наименование = &Наименование") ;

Теперь мы можем «родными» средствами статистики MS SQL проводить анализ и мониторинг постоянно в реальном времени, причем комплексно – сразу по всем базам на сервере. На рисунке ниже выделен запрос до (_2) и после оптимизации(_4).

 

Сам я использую свою обработку http://infostart.ru/public/145342/, в которой вы можете найти отчет «Нагрузка на сервере БД» который сообщит, вам какие запросы нагружали сервер больше всего за последний час работы. Период можно изменить в макете «НагружающиеЗапросы»: set @hours = 1; .

            avg_elapsed – среднее время на выполнение плана запроса

            total_elapsed_time – общее время затраченное на выполнение плана

            exec_count – количество выполнений плана

К сожалению, в данном методе мы не можем пометить некоторые запросы, например, генерируемые 1с при работе с объектной моделью (к счастью, они обычно просто определяются). Так же некоторые проблемы доставляет компилятор запросов, генерируя из вложенных запросов пакеты, но от этого можно избавиться, переписав сложные запросы  или помечая эти подзапросы. Главный из минусов это сложность обновлений модифицированных запросов.

Для автоматизации идентификации запросов можете исппользовать обработку (черновой вариант):

  1. выгружаем файлы конфигурации в каталог
  2. запускаем обработку, указываем в ней каталог куда выгрузили, жмем загрузить и выполнить
  3. двойной клик мыши на записи отображает сравнение файлов 
  4. загружаем файлы конфигурации, корректируем

Скачать файлы

Наименование Файл Версия Размер
Обработка создания текстовых идентификаторов в запросах 51
.epf 9,08Kb
13.12.12
51
.epf 9,08Kb Скачать

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Артур Аюханов (artbear) 12.12.12 01:46
2. Андрей Акулов (DrAku1a) 12.12.12 02:22
Сам я использую свою обработку http://infostart.ru/profile/110475/public/

Ссылка на список Ваших публикаций...

Эта обработка: http://infostart.ru/public/145342/?
3. qweasd qweasdzc (serega3333) 12.12.12 09:39
Вопщем все запросы надо перелопатить в итоге вручную, т.е. добавить эти идентификаторы? Автоматом никак нельзя это сделать?
4. AHDP (AHDP) 12.12.12 10:40
(3) serega3333,

В 8.3 штатно разложить на составляющие тексты их программно модифицировать и собрать обратно.
Только не забыть про временные таблицы в запросах.
serega3333; +1 Ответить 1
5. qweasd qweasdzc (serega3333) 12.12.12 10:48
(4) а новая эта фишка в 8.3, понял, спасибо!
6. Илья Фамилия (m191) 12.12.12 11:03
(3) serega3333,
Сейчас пытаюсь создать инструмент для автоматизации этой задачи. Идеи и предложения очень приветствуются.

Идея для всех версий платформы:
1 Сохраняем конфигурацию в файл, ее будем далее использовать для обновления и поддержки
2 В конфигураторе выгружаем модули
3 Обработкой помечаем запросы
4 Загружаем модули
5 Обновляем конфигурацию базы
6 Мониторим и оптимизируем
7 Все лучшие наработки переносим в сохраненную конфу
7. Сергей Куликов (ksvd) 12.12.12 11:26
"Простой способ" не очень уж и простой
8. AHDP (AHDP) 12.12.12 11:30
(6)
Предлагаю три режима:
1) весь пакет метить одной меткой с последующим суммированием времен выполнения;
2) каждый самостоятельный запрос отдельно;
3) каждый подзапрос и каждую часть запроса в "объеденить".

Делаешь через ТекстЗапроса = Заменить(ТекстЗапроса,,) или через непосредственное редактирование текста?
9. AHDP (AHDP) 12.12.12 11:32
(7) Ага, замер производительности ещё никто не отменял ;)
10. Илья Фамилия (m191) 12.12.12 11:49
(9) AHDP,
Как вы определите тормоза в высокочастотных запросах на базе с большим количеством пользователей?
Я ни одним инструментом кроме профайлера SQL не смог определить, что базу тормозят именно высокачастотные (вроде быстро работающие, но очень часто вызываемые), а не которые долго выполняются. Методика оптимизации
от 1С с их КИП в данном случае мне кажется бесполезной. Для работы с тех. журналом требуются нехилые ресурсы и навыки.
11. Сергей Старых (tormozit) 12.12.12 12:05
(10) Для работы с техножурналом на самом деле уже немало средств реализовано.

В инструментах разработчика я постарался обеспечить высокий уровень удобства работы с техножурналом. В частности высокочастотные запросы там также можно быстро обнаружить (есть свертки по текстам запросов с вырезанными параметрами и по строкам исходного кода). Также у Гилева есть свой вариант. Также у german есть Enterprise Integrator с профайлером.
12. Илья Фамилия (m191) 12.12.12 13:45
(11) tormozit,
Да, инструменты есть и не плохие. Однако, у большинства из них по моему мнению, есть один минус - накопление данных. Для примера, я не знаю как эффективно с помощью них круглосуточно выявлять проблеммные запросы в работающей базе с больщим количеством запросов и выявить динамику в течении часа, суток, месяца и т.д.
У всех методов есть плюсы и минусы. Имхо, тех. журнал это не тот инструмент которым можно полноценно мониторить базы.
13. Сергей Старых (tormozit) 12.12.12 14:02
(12) Техножурнал не есть конечный инструмент. Это лишь средство для журналирования важный событий. Имхо только через него и можно универсально мониторить базы, используя конечный инструменты.
14. Илья Фамилия (m191) 12.12.12 14:10
(8) AHDP,
>Делаешь через ТекстЗапроса = Заменить(ТекстЗапроса,,) или через непосредственное редактирование текста?
Мы пока все вручную. Помечаем только запросы которые мы изменяем или создаем,
в дефолтные запросы от поставщиков стараемся не трогать, что бы не создавать себе дополнительных проблем с обновлениями. Про режимы не понял.
15. Илья Фамилия (m191) 12.12.12 14:38
(13) tormozit,
Вот именно - это журнал событий, а не монитор. Появился он как побочный продукт разработки 1С.
16. AHDP (AHDP) 12.12.12 15:05
(10) Моя позиция такова, что оптимизировать нужно в первую очередь пиковую нагрузку. С запросами которых много и они быстро выполняются проще бороться мастабированием железа - гарантирована стоимость, сроки и результат.
(14) Это я для автоматического добавления в запросы меток. Например в пакете несколько запросов с приемлемым временем исполнения, а сам пакет ну никуда не годиться. Хочется иметь возможность увидеть всё время выполнения пакета и каждого запроса в отдельности.
17. Павел Баркетов (gallam99) 12.12.12 15:22
(12) Есть инструмент PerfExpert от softpoint.ru.
http://www.softpoint.ru/products_id3.htm
Позволяет накапливать данные и возвращаться к проблемному интервалу времени для анализа.
19. Илья Фамилия (m191) 13.12.12 17:46
Минус - платная. Сами пользовались? Какие впечатления?

UPD Добавил к статье обработку для выставления идентификаторов.
20. Илья Фамилия (m191) 13.12.12 17:53
(16) AHDP,
Моя позиция такова, что оптимизировать нужно в первую очередь пиковую нагрузку. С запросами которых много и они быстро выполняются проще бороться мастабированием железа - гарантирована стоимость, сроки и результат.


Не всегда можно это сделать с помощью железа: ограниченый бюджет, сроки ну и достижения предела по ресурсу (например сетевой канал, скорость шины). Иногда лучше и дешевле изменить алгоритм работы.
21. Александр Никитин (ManyakRus) 17.12.12 16:13
Activity Monitor выдаёт:

SELECT
@P1
FROM _InfoRg34 T1 WITH(NOLOCK)

Все слова и цифры заменяет на @P1, а как вам удалось сделать чтоб писал по человечески вместо @P1 ?
(SQL SERVER 2008 R2)
22. Илья Фамилия (m191) 17.12.12 16:32
(21) ManyakRus,
Ничего специально не далали, выдает по умолчанию. Возможо это 1С так делает (у нас 8.1)?
23. Александр Никитин (ManyakRus) 18.12.12 10:57
у меня 1C 8.2.16.352,
не получается так :(
24. Илья Фамилия (m191) 18.12.12 17:14
Проверил, действительно в 8.2 константы передает как параметры - печалька.
Изыскания привели к созданию такого запроса:
	З = Новый Запрос("ВЫБРАТЬ
	                 |	""111"" КАК идзапроса,
	                 |	МАКСИМУМ(""222"") КАК идзапроса1,
	                 |	ВЫБОР
	                 |		КОГДА ИСТИНА
	                 |			ТОГДА ""333""
	                 |		ИНАЧЕ ""444""
	                 |	КОНЕЦ КАК идзапроса2");
:)
...Показать Скрыть


Не знаю как это вяжится со стандартом SQL и как ситуация в других СУБД.
25. Александр Никитин (ManyakRus) 19.12.12 10:09
работают оба метода :)
(максимум и выбор)
Расставлю везде метки :)

SELECT
MAX(N'222'),
FROM _InfoRg34 T1 WITH(NOLOCK)

SELECT
CASE WHEN (N'111' = N'222') THEN N'333' ELSE N'444' END
FROM _InfoRg34 T1 WITH(NOLOCK)
26. Андрей Иваненко (AnderWonder) 30.01.13 18:21
Не получается идентифицировать таким образом запрос из СКД, похоже он модифицируется вообще в какой-то непонятный набор с кучей временных таблиц (.
27. Александр Никитин (ManyakRus) 30.01.13 19:42
временные таблицы не идентифицируются,
28. Александр Никитин (ManyakRus) 30.01.13 19:43
временные таблицы не идентифицируются,
а они тоже много пожирают,
в БД у них видимо команды инсерт вместо селект.
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа