Index hints in X++ again

[trud]

Все же есть положительные моменты, что MS стала следить за работой продукта в реальной жизни. Вот теперь и Index hints решили вернуть(видно кто-то уже наткнулся parameters sniffing в виде неравном распределении продуктов по складам или кодов партий вида "Без партии")

https://docs.microsoft.com/en-us/dyn...form-update-23

[Logger]

Они бы еще позволили выборочно forceliterals включать для отдельных полей а также для update_recordset.

Совсем была бы красота.

[fed]

Цитата:

Сообщение от trud

Все же есть положительные моменты, что MS стала следить за работой продукта в реальной жизни. Вот теперь и Index hints решили вернуть(видно кто-то уже наткнулся parameters sniffing в виде неравном распределении продуктов по складам или кодов партий вида "Без партии")

https://docs.microsoft.com/en-us/dyn...form-update-23

На мой взгляд, потребность в index hints говорит о том что SQL Server (точнее Azure SQL) не присмотрен. Если статистика регулярно обновляется, сервер кривые планы не особо часто генерит. Кроме того - мы ведь этот хинт можем только в свой код добавить, соответственно - проще туда же поставить forceliterals и добиться правильного плана исполнения более системным образом...
P.S. Кстати - на хорошо администрируемом SQL Server должен крутиться скрипт, которые анализирует статистику запросов. И если какой-то запрос потребляет больше, скажем, 15% общих ресурсов, шлется какое-то оповещение админу. А тот уже анализирует план, вычищает его из кэша если он плохой и информирует разработчиков что такой-то запрос что-то часто кривит.

[AlexeyS]

Цитата:

Сообщение от fed

На мой взгляд, потребность в index hints говорит о том что SQL Server (точнее Azure SQL) не присмотрен. Если статистика регулярно обновляется, сервер кривые планы не особо часто генерит. Кроме того - мы ведь этот хинт можем только в свой код добавить, соответственно - проще туда же поставить forceliterals и добиться правильного плана исполнения более системным образом...
P.S. Кстати - на хорошо администрируемом SQL Server должен крутиться скрипт, которые анализирует статистику запросов. И если какой-то запрос потребляет больше, скажем, 15% общих ресурсов, шлется какое-то оповещение админу. А тот уже анализирует план, вычищает его из кэша если он плохой и информирует разработчиков что такой-то запрос что-то часто кривит.

Давным-давно, когда деревья были большими, читал про планы MS автоматизировать подобную рутинную работу DBA. Видимо это пока осталось в планах? Теоретически, подобные вещи должны быть "из коробки".

[trud]

Вроде там в принципе невозможно победить parameters sniffing. т.е. forceliterals конечно поможет, но построение плана это очень затратная операция(я как-то давно тестил, там получились времена на порядки больше + нагрузка на CPU), т.е. на типовых вещах типа разноски журнала это не очень выход. остается или указывать index hint или прописывать план через sp_create_plan_guide. хотя обещают адаптивные планы, но по видимому еще не очень работает

[belugin]

Цитата:

Сообщение от AlexeyS

Давным-давно, когда деревья были большими, читал про планы MS автоматизировать подобную рутинную работу DBA. Видимо это пока осталось в планах? Теоретически, подобные вещи должны быть "из коробки".

https://docs.microsoft.com/en-us/dyn...roubleshooting

[fed]

Цитата:

Сообщение от trud

Вроде там в принципе невозможно победить parameters sniffing. т.е. forceliterals конечно поможет, но построение плана это очень затратная операция(я как-то давно тестил, там получились времена на порядки больше + нагрузка на CPU), т.е. на типовых вещах типа разноски журнала это не очень выход. остается или указывать index hint или прописывать план через sp_create_plan_guide. хотя обещают адаптивные планы, но по видимому еще не очень работает

Ты знаешь, с тех пор как я начал с аксаптой работать, производительность жестких дисков (если не держать базу на SDD) возросла раз в 20-30-40. Производительность процессоров - раз в 500 наверное. Поэтому накладняк на построение плана запроса с легкостью перекрывается экономией на времени исполнения кривого плана запроса.
Плюс - заметные затраты на построение плана запроса происходят при большом числе таблиц в запросе (типа штук 8-10). А в такие запросы особо index hint не попихаешь, поскольку там скорее собака в типе джойна зарыта. (А тут всего один хинт есть - forcenestedloops, а этого явно не хватит).

[trud]

Цитата:

Сообщение от fed

Производительность процессоров - раз в 500 наверное. Поэтому накладняк на построение плана запроса с легкостью перекрывается экономией на времени исполнения кривого плана запроса.

500 ты перегнул. мы же говорим о однопоточном выполнении. т.е. как был 10 лет назад пентиум 4, 2.5гц, так и сейчас ненамного ушли от этой частоты. т.е. в среднем сейчас процессор только в 2 раза быстрее чем был 10 лет назад.
https://www.cpubenchmark.net/singleThread.html

типичный пример - это InventSum.findsum, если туда впихнуть forceliteral то все очень замедлится. тестировал как-то давно, надо будет при случае повторить

[fed]

Цитата:

Сообщение от trud

500 ты перегнул. мы же говорим о однопоточном выполнении. т.е. как был 10 лет назад пентиум 4, 2.5гц, так и сейчас ненамного ушли от этой частоты. т.е. в среднем сейчас процессор только в 2 раза быстрее чем был 10 лет назад.
https://www.cpubenchmark.net/singleThread.html

Ну моим первым серверным процессором на проекте с Axapta 2.5 был Xeon 700. В твоей табличке его нету, но судя по всему он таки раз в 10 отличается от современных серверных процессоров чуть выше среднего.а помнижив на 24 ядер - получаем 240 раз.Так что ошибся я всего в два раза.
Конечно компиляцию плана запроса не распараллелишь, но все равно реально сервер этим делом мне всерьез загрузить не удавалось
А по поводу findSum() - попробуй проверить. Просто мне на моей практике неоднократно приходилось ставить в разные места forceliterals и ни разу это к ухудшению производительности не приводило (хотя таки да - такие популярные места, как этот метод, я не правил).

[AlexeyS]

Цитата:

Сообщение от fed

Ты знаешь, с тех пор как я начал с аксаптой работать, производительность жестких дисков (если не держать базу на SDD) возросла раз в 20-30-40. Производительность процессоров - раз в 500 наверное. Поэтому накладняк на построение плана запроса с легкостью перекрывается экономией на времени исполнения кривого плана запроса.
Плюс - заметные затраты на построение плана запроса происходят при большом числе таблиц в запросе (типа штук 8-10). А в такие запросы особо index hint не попихаешь, поскольку там скорее собака в типе джойна зарыта. (А тут всего один хинт есть - forcenestedloops, а этого явно не хватит).

Похоже БД все чаще становится бутылочным горлышком. Например X5 работают на SAP и пишут что вынесли на уровень сервера приложений часть join-запросов, чтобы снизить нагрузку на БД.

[Удвой Покуров]

Бесстрашные ребята. Подобная мультипликация обычно требует отдельного лицензирования! Хотя, Quod licet Jovi, non licet bovi - возможно, по их контракту все это входит в лицензионное соглашение, лишь бы работало...

[fed]

Цитата:

Сообщение от AlexeyS

Похоже БД все чаще становится бутылочным горлышком. Например X5 работают на SAP и пишут что вынесли на уровень сервера приложений часть join-запросов, чтобы снизить нагрузку на БД.

БД всегда была бутылочным горлышком. Я за те 10 лет, которые я всерьез занимаюсь тюнингом производительности Ax, столкнулся всего с одним случаем, когда проблема была не в БД: Разработчики заказчика поставили Full Table Cache на часто обновляемую таблицу. В результате, большую часть времени AOS в кластере тратил на перечитывание этой таблицы. (И, кстати, таблица была слишком большая чтобы в память поместиться, так что сервера ее на локальный диск складывали). Все остальные проблемы так или иначе вызывались торможением БД.
Ну и вообще ситуации когда система 300000 запросов в секунду к серверу отправляет, говорит о некоторой кривости функционала.

[AlexeyS]

Цитата:

Сообщение от fed

БД всегда была бутылочным горлышком. Я за те 10 лет, которые я всерьез занимаюсь тюнингом производительности Ax, столкнулся всего с одним случаем, когда проблема была не в БД: Разработчики заказчика поставили Full Table Cache на часто обновляемую таблицу. В результате, большую часть времени AOS в кластере тратил на перечитывание этой таблицы. (И, кстати, таблица была слишком большая чтобы в память поместиться, так что сервера ее на локальный диск складывали). Все остальные проблемы так или иначе вызывались торможением БД.
Ну и вообще ситуации когда система 300000 запросов в секунду к серверу отправляет, говорит о некоторой кривости функционала.

Работа с транзакционной БД всегда самая медленная часть, это и так понятно. Я немного про другое, про приемлемую скорость работы, когда даже оттюненая БД не тянет.
Когда я занимался производительностью АХ, значительная часть проблем была не в базе как таковой, а в том, что по ней статистика была устаревшая и индексов не хватало, т.е просто недостаточно обслуживалась. А еще - проблемы с кривым кодом, когда, например, настроечная таблица не закеширована на ОАС и постоянно идут мелкие запросы, отжирающие ресурсы. Или запрос к большой таблице уходит с пустыми Range. Или нужно разделить одну большую транзакцию на несколько маленьких. С одной стороны это скорее проблемы приложения, но в итоге все равно если не разбираться почему, то мнение одно - тормозит БД.

[MikeR]

Цитата:

Сообщение от fed

...
Плюс - заметные затраты на построение плана запроса происходят при большом числе таблиц в запросе (типа штук 8-10). А в такие запросы особо index hint не попихаешь, поскольку там скорее собака в типе джойна зарыта. (А тут всего один хинт есть - forcenestedloops, а этого явно не хватит).

Согласен с нормализацией Майкрософт перестарался сильно. Для high load это зло.
Но есть ощущение то, что сделали с Axapta high load и не нужен. Главное - это показатели в фин отчетности, что прибыть растет, инвесторы инвестят, а на остальное нас@ть. Не знаю как это на индише.

[trud]

Цитата:

Сообщение от fed

Конечно компиляцию плана запроса не распараллелишь, но все равно реально сервер этим делом мне всерьез загрузить не удавалось

В общем проверил на новых версиях SQL и одном из топовых текущих процессоров - компиляция запроса это по прежнему "очень тяжело". В inventSum с inventDim forceliterals лучше не вставлять

подробно в статье
https://denistrunin.netlify.com/forc...ePlaceholders/

[fed]

Цитата:

Сообщение от trud

В общем проверил на новых версиях SQL и одном из топовых текущих процессоров - компиляция запроса это по прежнему "очень тяжело". В inventSum с inventDim forceliterals лучше не вставлять
Вложение 12162
подробно в статье
https://denistrunin.netlify.com/forc...ePlaceholders/

Я все-таки спрошу - сколько у тебя на проце ядер было и сколько памяти?
Просто если тебе удалось одно ядро до 100% забить - я ничуть не удивлюсь. Но вот в ситуации с 32 процессорами, компиляция плана запроса раскидывается на несколько ядер и таких катастрофических результатов не дает. Ну и да - если запрос относительно легкий, то особых проблем и без перекомпиляции не будет. Но вот у меня был один клиент, у которого было порядка 10-15 видов готовой продукции и по каждому виду продукции порядка десятков или сотен тысяч батчей. Кроме того было порядка нескольких сотен (может тысячи полторы) вспомогательной номенклатуры, по которой батчей не было и движений было не так уж много. Соответственно запрос при проверке списания ГП по складу суммировал несколько десятков/сотен тысяч записей в inventSum, а аналогичный запрос по вспомогательной номенклатуре - всего несколько записей. В первом случае - время запроса составляло 2-5 секунд, во втором - наверное 20-30 миллисекунд. И я не уверен что вот в такой конфигурации, выигрыш forceplaceholders был бы таким уж чрезвычайным. Если у тебя запрос исполняется 5 секунд, трата даже 200-300 миллисекунд на его компиляцию не так уж заметна

[skuull]

Я просто оставлю это здесь http://www.sommarskog.se/query-plan-mysteries.html , много текста но лучше много чем мало

[trud]

Цитата:

Сообщение от fed

Я все-таки спрошу - сколько у тебя на проце ядер было и сколько памяти? Но вот в ситуации с 32 процессорами, компиляция плана запроса раскидывается на несколько ядер и таких катастрофических результатов не дает.

Ну я 2 случая проверил - 6с и 64ГБ, 24с и 110ГБ. Так и пользователей обычно больше чем 1. Плюс параллельное выполнение отключают всегда, этож OLTP

Цитата:

Сообщение от fed

В первом случае - время запроса составляло 2-5 секунд, во втором - наверное 20-30 миллисекунд. И я не уверен что вот в такой конфигурации, выигрыш forceplaceholders был бы таким уж чрезвычайным. Если у тебя запрос исполняется 5 секунд, трата даже 200-300 миллисекунд на его компиляцию не так уж заметна

Ну в ряде случаев index hint позволит тебе убрать эти 200-300мс(ну и плюс значительно снизить нагрузку), т.е. это один из инструментов. т.е. с forceliterals у тебя будет 200 на компиляцию + 20 на выполнение. 220 это же гораздо хуже чем просто 20 на выполнение

В общем надо проверять кто решится поставить forceliterals в InventSum::findSum и отписаться о результатах

[fed]

Цитата:

Сообщение от trud

Ну я 2 случая проверил - 6с и 64ГБ, 24с и 110ГБ. Так и пользователей обычно больше чем 1. Плюс параллельное выполнение отключают всегда, этож OLTP

Отключенное параллельное исполнение отключает параллельное исполнение одного запроса. Если у меня куча ядер и куча пользователей, то каждое отдельное ядро может параллельно компилировать/исполнять запросы пришедшие от разных пользователей. Просто твой тест несколько вырожденный. Все-таки в реальности пользователей много и у каждого компиляция идет на своем проце. Во вторых - в реальной ситуации пользователи редко шлют такие запросы пачками. При более или менее правильном программировании уйдет всего один запрос с group by. Ну и наконец - я не предлагаю во всех случаях ставить forceliterals. Я предлагаю его ставить только если у тебя сильно неоднородные данные в каких-то таблицах. Просто в ситуации с моим клиентом там index hint тоже не особо помог бы. Потому что в зависимости от типа номеклатуры там либо надо сначала искать по inventDim и потом джойнится к InventSum, либо наоборот - сначала искать по inventSum, а потом джойнится к InventDim.

Вообще идеальным вариантом было бы, если бы Ax мог бы передавать какой-то тэг для SQL, а внутри SQL можно было бы этот тэг матчить с plan guide. Надо будет посмотреть что они в SQL Server 2017 с plan guide и query store сделали. Тогда в зависимости от типа номенклатуры в моем примере, можно было бы разные тэги передавать и в query store как-то их матчить планам запроса.

[Logger]

Цитата:

Сообщение от skuull

Я просто оставлю это здесь http://www.sommarskog.se/query-plan-mysteries.html , много текста но лучше много чем мало

Вот тут есть русский перевод
http://www.queryprocessor.ru/fast-in...-in-app-part1/