Index hints in X++ again

[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/

[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 миллисекунд на его компиляцию не так уж заметна

[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]

Цитата:

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

Ну и наконец - я не предлагаю во всех случаях ставить forceliterals. Я предлагаю его ставить только если у тебя сильно неоднородные данные в каких-то таблицах.

Лучше бы они в дополнение к index hint разрешили бы применять forceliterals к конкретным полям в которых наблюдается неравномерность распределения данных. Вот это была бы польза. Особенно если это можно было бы админам настраивать в SQLStorage табличке. Тогда можно без кастомизаций обходиться и действовало бы везде в системе.

А пока мы можем включать литералы только для dataAreaId и Partition
Дискриминация получается.

[trud]

Цитата:

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

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

Ну что-то кстати обещают в SQL2019
https://www.brentozar.com/archive/20...memory-grants/