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. Видимо это пока осталось в планах? Теоретически, подобные вещи должны быть "из коробки".

[belugin]

Цитата:

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

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

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

[trud]

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

[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 и ни разу это к ухудшению производительности не приводило (хотя таки да - такие популярные места, как этот метод, я не правил).

[trud]

Цитата:

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

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

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

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

[AlexeyS]

Цитата:

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

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

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

[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 и не нужен. Главное - это показатели в фин отчетности, что прибыть растет, инвесторы инвестят, а на остальное нас@ть. Не знаю как это на индише.

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

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

[skuull]

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

[Logger]

Цитата:

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

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

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