AXForum  
Вернуться   AXForum > Прочие обсуждения > Курилка
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 06.12.2018, 08:27   #1  
trud is offline
trud
Участник
Лучший по профессии 2017
 
769 / 998 (35) +++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Index hints in X++ again
Все же есть положительные моменты, что MS стала следить за работой продукта в реальной жизни. Вот теперь и Index hints решили вернуть(видно кто-то уже наткнулся parameters sniffing в виде неравном распределении продуктов по складам или кодов партий вида "Без партии")

https://docs.microsoft.com/en-us/dyn...form-update-23
За это сообщение автора поблагодарили: Logger (1).
Старый 06.12.2018, 09:26   #2  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,217 / 2116 (77) +++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Они бы еще позволили выборочно forceliterals включать для отдельных полей а также для update_recordset.

Совсем была бы красота.
Старый 06.12.2018, 10:21   #3  
online
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,504 / 4772 (165) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от 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% общих ресурсов, шлется какое-то оповещение админу. А тот уже анализирует план, вычищает его из кэша если он плохой и информирует разработчиков что такой-то запрос что-то часто кривит.
Старый 06.12.2018, 11:13   #4  
AlexeyS is offline
AlexeyS
Участник
 
382 / 294 (10) ++++++
Регистрация: 15.06.2004
Адрес: москва
Цитата:
Сообщение от fed Посмотреть сообщение
На мой взгляд, потребность в index hints говорит о том что SQL Server (точнее Azure SQL) не присмотрен. Если статистика регулярно обновляется, сервер кривые планы не особо часто генерит. Кроме того - мы ведь этот хинт можем только в свой код добавить, соответственно - проще туда же поставить forceliterals и добиться правильного плана исполнения более системным образом...
P.S. Кстати - на хорошо администрируемом SQL Server должен крутиться скрипт, которые анализирует статистику запросов. И если какой-то запрос потребляет больше, скажем, 15% общих ресурсов, шлется какое-то оповещение админу. А тот уже анализирует план, вычищает его из кэша если он плохой и информирует разработчиков что такой-то запрос что-то часто кривит.
Давным-давно, когда деревья были большими, читал про планы MS автоматизировать подобную рутинную работу DBA. Видимо это пока осталось в планах? Теоретически, подобные вещи должны быть "из коробки".
Старый 06.12.2018, 12:24   #5  
trud is offline
trud
Участник
Лучший по профессии 2017
 
769 / 998 (35) +++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Вроде там в принципе невозможно победить parameters sniffing. т.е. forceliterals конечно поможет, но построение плана это очень затратная операция(я как-то давно тестил, там получились времена на порядки больше + нагрузка на CPU), т.е. на типовых вещах типа разноски журнала это не очень выход. остается или указывать index hint или прописывать план через sp_create_plan_guide. хотя обещают адаптивные планы, но по видимому еще не очень работает
Старый 06.12.2018, 12:26   #6  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,291 / 2492 (92) +++++++++
Регистрация: 16.01.2004
Адрес: Москва
Записей в блоге: 5
Цитата:
Сообщение от AlexeyS Посмотреть сообщение
Давным-давно, когда деревья были большими, читал про планы MS автоматизировать подобную рутинную работу DBA. Видимо это пока осталось в планах? Теоретически, подобные вещи должны быть "из коробки".
https://docs.microsoft.com/en-us/dyn...roubleshooting
__________________
https://axcoder.github.io
За это сообщение автора поблагодарили: trud (1), alex55 (1), AlexeyS (2).
Старый 06.12.2018, 12:33   #7  
online
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,504 / 4772 (165) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от trud Посмотреть сообщение
Вроде там в принципе невозможно победить parameters sniffing. т.е. forceliterals конечно поможет, но построение плана это очень затратная операция(я как-то давно тестил, там получились времена на порядки больше + нагрузка на CPU), т.е. на типовых вещах типа разноски журнала это не очень выход. остается или указывать index hint или прописывать план через sp_create_plan_guide. хотя обещают адаптивные планы, но по видимому еще не очень работает
Ты знаешь, с тех пор как я начал с аксаптой работать, производительность жестких дисков (если не держать базу на SDD) возросла раз в 20-30-40. Производительность процессоров - раз в 500 наверное. Поэтому накладняк на построение плана запроса с легкостью перекрывается экономией на времени исполнения кривого плана запроса.
Плюс - заметные затраты на построение плана запроса происходят при большом числе таблиц в запросе (типа штук 8-10). А в такие запросы особо index hint не попихаешь, поскольку там скорее собака в типе джойна зарыта. (А тут всего один хинт есть - forcenestedloops, а этого явно не хватит).
Старый 06.12.2018, 13:53   #8  
trud is offline
trud
Участник
Лучший по профессии 2017
 
769 / 998 (35) +++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от fed Посмотреть сообщение
Производительность процессоров - раз в 500 наверное. Поэтому накладняк на построение плана запроса с легкостью перекрывается экономией на времени исполнения кривого плана запроса.
500 ты перегнул. мы же говорим о однопоточном выполнении. т.е. как был 10 лет назад пентиум 4, 2.5гц, так и сейчас ненамного ушли от этой частоты. т.е. в среднем сейчас процессор только в 2 раза быстрее чем был 10 лет назад.
https://www.cpubenchmark.net/singleThread.html

типичный пример - это InventSum.findsum, если туда впихнуть forceliteral то все очень замедлится. тестировал как-то давно, надо будет при случае повторить
Старый 06.12.2018, 16:38   #9  
online
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,504 / 4772 (165) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от trud Посмотреть сообщение
500 ты перегнул. мы же говорим о однопоточном выполнении. т.е. как был 10 лет назад пентиум 4, 2.5гц, так и сейчас ненамного ушли от этой частоты. т.е. в среднем сейчас процессор только в 2 раза быстрее чем был 10 лет назад.
https://www.cpubenchmark.net/singleThread.html
Ну моим первым серверным процессором на проекте с Axapta 2.5 был Xeon 700. В твоей табличке его нету, но судя по всему он таки раз в 10 отличается от современных серверных процессоров чуть выше среднего.а помнижив на 24 ядер - получаем 240 раз.Так что ошибся я всего в два раза.
Конечно компиляцию плана запроса не распараллелишь, но все равно реально сервер этим делом мне всерьез загрузить не удавалось
А по поводу findSum() - попробуй проверить. Просто мне на моей практике неоднократно приходилось ставить в разные места forceliterals и ни разу это к ухудшению производительности не приводило (хотя таки да - такие популярные места, как этот метод, я не правил).

Последний раз редактировалось fed; 06.12.2018 в 16:57.
Старый 10.12.2018, 15:29   #10  
AlexeyS is offline
AlexeyS
Участник
 
382 / 294 (10) ++++++
Регистрация: 15.06.2004
Адрес: москва
Цитата:
Сообщение от fed Посмотреть сообщение
Ты знаешь, с тех пор как я начал с аксаптой работать, производительность жестких дисков (если не держать базу на SDD) возросла раз в 20-30-40. Производительность процессоров - раз в 500 наверное. Поэтому накладняк на построение плана запроса с легкостью перекрывается экономией на времени исполнения кривого плана запроса.
Плюс - заметные затраты на построение плана запроса происходят при большом числе таблиц в запросе (типа штук 8-10). А в такие запросы особо index hint не попихаешь, поскольку там скорее собака в типе джойна зарыта. (А тут всего один хинт есть - forcenestedloops, а этого явно не хватит).
Похоже БД все чаще становится бутылочным горлышком. Например X5 работают на SAP и пишут что вынесли на уровень сервера приложений часть join-запросов, чтобы снизить нагрузку на БД.
Старый 10.12.2018, 15:43   #11  
Удвой Покуров is offline
Удвой Покуров
Участник
 
415 / 198 (7) ++++++
Регистрация: 03.04.2011
Бесстрашные ребята. Подобная мультипликация обычно требует отдельного лицензирования! Хотя, Quod licet Jovi, non licet bovi - возможно, по их контракту все это входит в лицензионное соглашение, лишь бы работало...
Старый 10.12.2018, 15:55   #12  
online
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,504 / 4772 (165) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от AlexeyS Посмотреть сообщение
Похоже БД все чаще становится бутылочным горлышком. Например X5 работают на SAP и пишут что вынесли на уровень сервера приложений часть join-запросов, чтобы снизить нагрузку на БД.
БД всегда была бутылочным горлышком. Я за те 10 лет, которые я всерьез занимаюсь тюнингом производительности Ax, столкнулся всего с одним случаем, когда проблема была не в БД: Разработчики заказчика поставили Full Table Cache на часто обновляемую таблицу. В результате, большую часть времени AOS в кластере тратил на перечитывание этой таблицы. (И, кстати, таблица была слишком большая чтобы в память поместиться, так что сервера ее на локальный диск складывали). Все остальные проблемы так или иначе вызывались торможением БД.
Ну и вообще ситуации когда система 300000 запросов в секунду к серверу отправляет, говорит о некоторой кривости функционала.
Старый 11.12.2018, 13:22   #13  
AlexeyS is offline
AlexeyS
Участник
 
382 / 294 (10) ++++++
Регистрация: 15.06.2004
Адрес: москва
Цитата:
Сообщение от fed Посмотреть сообщение
БД всегда была бутылочным горлышком. Я за те 10 лет, которые я всерьез занимаюсь тюнингом производительности Ax, столкнулся всего с одним случаем, когда проблема была не в БД: Разработчики заказчика поставили Full Table Cache на часто обновляемую таблицу. В результате, большую часть времени AOS в кластере тратил на перечитывание этой таблицы. (И, кстати, таблица была слишком большая чтобы в память поместиться, так что сервера ее на локальный диск складывали). Все остальные проблемы так или иначе вызывались торможением БД.
Ну и вообще ситуации когда система 300000 запросов в секунду к серверу отправляет, говорит о некоторой кривости функционала.
Работа с транзакционной БД всегда самая медленная часть, это и так понятно. Я немного про другое, про приемлемую скорость работы, когда даже оттюненая БД не тянет.
Когда я занимался производительностью АХ, значительная часть проблем была не в базе как таковой, а в том, что по ней статистика была устаревшая и индексов не хватало, т.е просто недостаточно обслуживалась. А еще - проблемы с кривым кодом, когда, например, настроечная таблица не закеширована на ОАС и постоянно идут мелкие запросы, отжирающие ресурсы. Или запрос к большой таблице уходит с пустыми Range. Или нужно разделить одну большую транзакцию на несколько маленьких. С одной стороны это скорее проблемы приложения, но в итоге все равно если не разбираться почему, то мнение одно - тормозит БД.
Старый 11.12.2018, 16:07   #14  
MikeR is offline
MikeR
MCT
Аватар для MikeR
MCBMSS
Лучший по профессии 2015
Лучший по профессии 2014
 
1,601 / 618 (24) +++++++
Регистрация: 28.11.2005
Адрес: просто землянин
Цитата:
Сообщение от fed Посмотреть сообщение
...
Плюс - заметные затраты на построение плана запроса происходят при большом числе таблиц в запросе (типа штук 8-10). А в такие запросы особо index hint не попихаешь, поскольку там скорее собака в типе джойна зарыта. (А тут всего один хинт есть - forcenestedloops, а этого явно не хватит).
Согласен с нормализацией Майкрософт перестарался сильно. Для high load это зло.
Но есть ощущение то, что сделали с Axapta high load и не нужен. Главное - это показатели в фин отчетности, что прибыть растет, инвесторы инвестят, а на остальное нас@ть. Не знаю как это на индише.
__________________
Axapta book for developer
Старый 12.12.2018, 16:52   #15  
trud is offline
trud
Участник
Лучший по профессии 2017
 
769 / 998 (35) +++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от fed Посмотреть сообщение
Конечно компиляцию плана запроса не распараллелишь, но все равно реально сервер этим делом мне всерьез загрузить не удавалось
В общем проверил на новых версиях SQL и одном из топовых текущих процессоров - компиляция запроса это по прежнему "очень тяжело". В inventSum с inventDim forceliterals лучше не вставлять
Нажмите на изображение для увеличения
Название: Compare1.png
Просмотров: 294
Размер:	15.9 Кб
ID:	12162
подробно в статье
https://denistrunin.netlify.com/forc...ePlaceholders/
За это сообщение автора поблагодарили: Logger (8), belugin (15), fed (10), gl00mie (5), sukhanchik (8), axotnik88 (1).
Старый 13.12.2018, 10:46   #16  
online
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,504 / 4772 (165) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от 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 миллисекунд на его компиляцию не так уж заметна
Старый 13.12.2018, 12:42   #17  
skuull is offline
skuull
Участник
Most Valuable Professional
Лучший по профессии 2014
 
647 / 669 (24) +++++++
Регистрация: 08.03.2013
Адрес: ХЗ
Я просто оставлю это здесь http://www.sommarskog.se/query-plan-mysteries.html , много текста но лучше много чем мало
За это сообщение автора поблагодарили: trud (1), Logger (3).
Старый 13.12.2018, 13:20   #18  
trud is offline
trud
Участник
Лучший по профессии 2017
 
769 / 998 (35) +++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от 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 и отписаться о результатах
Старый 13.12.2018, 13:46   #19  
online
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,504 / 4772 (165) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от 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 как-то их матчить планам запроса.

Последний раз редактировалось fed; 13.12.2018 в 13:53.
Старый 13.12.2018, 14:03   #20  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,217 / 2116 (77) +++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от skuull Посмотреть сообщение
Я просто оставлю это здесь http://www.sommarskog.se/query-plan-mysteries.html , много текста но лучше много чем мало
Вот тут есть русский перевод
http://www.queryprocessor.ru/fast-in...-in-app-part1/
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Где искать European Union Consumer Price Index? Spider Детская 3 24.07.2006 22:25
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 10:05.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.