Denis Trunin's Blogs: Resolving performance issues caused by parameters sniffing in AX2012 and D365FO

[fed]

Цитата:

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

"Переиндексацию для борьбы с неправильными планами" я видимо тоже пропустил - можете дать ссылку на первоисточник? А если не зацикливаться на планах исполнения, то из некоторых сценариев (например, массовые forwarded records) - выходов кроме регулярной перестройки индексов (ну или изменения схемы) в общем-то и нет

По моим наблюдениям, если перестроение индексов по таблице помогло с кривым планом исполнения, то в 98% случаев это случилось только потому что при перестроении был сброшен план исполнения, а следующий план исполнения был более удачным (то есть - имеем ситуацию неудачного parameters sniffing и plan guide может помочь). И только примерно в 2% случаев, перестроение индексов помогает действительно потому что индекс был фрагментирован или в нем было много ghost records после массового удаления и тп.
То есть - таки да, если кто-то предлагает лечить проблему медленного исполнения запроса перестроением индекса (без предложения проанализировать план запроса, почистить кэш планов хотя бы, обновить статистику и тд и тп), то это для меня - признак сомнительной квалификации автора.
Мне, правда, применение plan guide тоже кажется механизмом последнего шанса, когда систему постоянно глючит на одном и том же запросе и регулярное обновление статистики не помогает, но мои сомнения по поводу рекомендации перестраивать индексы на любой чих это не отменяет.

[Vadik]

Цитата:

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

По моим наблюдениям, если перестроение индексов по таблице помогло с кривым планом исполнения, то в 98% случаев это случилось только потому что при перестроении был сброшен план исполнения, а следующий план исполнения был более удачным (то есть - имеем ситуацию неудачного parameters sniffing и plan guide может помочь). И только примерно в 2% случаев, перестроение индексов помогает действительно потому что индекс был фрагментирован или в нем было много ghost records после массового удаления и тп.

Согласен

Цитата:

Мне, правда, применение plan guide тоже кажется механизмом последнего шанса, когда систему постоянно глючит на одном и том же запросе и регулярное обновление статистики не помогает, но мои сомнения по поводу рекомендации перестраивать индексы на любой чих это не отменяет

Ну так где рекомендация-то? Я вижу список вещей которые можно попробовать, но никак не пошаговый план действий

As a first step… try to tune expensive code / queries
• Add/change indexes
• Increase selectivity
• Add hints
• Rebuild indexes
• Update statistics
• Apply other code changes (e.g. change pattern)

Т.е. мы приписываем автору что-то, чего он не заявлял, и на этом основании строим свои дальнейшие умозаключения. Удобно

[trud]

Так а как по вашему надо решать сниффинг параметров?

Один из комментов, это собственно все, гугл ничего не ищет по этому поводу

Цитата:

I had a discussion about APRC feature with MS and they confirmed the feature is activated in production environments since October 2019 and some plans are automatically forced based on certain conditions. To reset forced planned, I was advised to update statistics or make schema modification (new index, field, index rebuild, and so on).

[Vadik]

Цитата:

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

Так а как по вашему надо решать сниффинг параметров?

"Прямо сейчас" - обновление статистики (сбросив закешированный план), сохранить план и в фоне разбираться с тем, что протухло. Чинить - в AOT (индекс который должен подбираться даже при тестировании с "плохим" значением параметра, либо код). Если будут рецидивы в процессе починки, можно создать plan guide (после починки - снести). По крайней мере, так не будет пасхалок в виде "в UAT работает не так как в продуктиве", "работает в пяти компаниях из десяти" и т.п.

Я возможно повторюсь сейчас. Я не против plan guides как таковых и пользуюсь ими периодически. Но так как они блокируют оптимизатор, отношусь к ним как ко временным надстройкам (костылям). Поставить клиента со сломанной ногой на костыли можно быстро и с ними ему даже будет какое-то время удобнее (чем без них). Заставлять с ними жить вечно и добавлять новые (с этими - на дачу, с этими - в магазин) - на мой взгляд, уже неправильно

Цитата:

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

Понимаешь, на самом деле надо не пробовать, а для начала посмотреть кэш планов запросов и для самых тяжелых запросов посмотреть на сами планы запросов и попытаться понять что там не так. После этого уже можно принимать осмысленные решения - сам запрос менять, дополнительные индексы строить, попробовать статистику обновлять или еще чего-то делать.

Я людям которые не понимают того, что надо сделать чтобы понять в чем проблема, вообще поостерегся бы какие-то рекомендации давать

Цитата:

Сам по себе подход "можно попробовать", наводит на мысль что этот документ родился из алгоритма так называемого "checklist tuner". Это такой персонаж, туповатый, но самоуверенный, и как правильно титульной (для микрософта) национальности, который "разбирается" с твоими проблемами производительности, заставляя тебя выполнять все шаги из его чеклиста. И попытки ему как-то объяснить что в случае проблем со сводным планированием чистить таблицы SalesParm*/PurchParm* несколько странно, к особым результатам не приводят. (Кстати -даже странно что рекомендация чистить таблицы параметров пропущена из этого замечательного документа). Соответственно - отношение ко всем этим чеклистам у меня исключительно скептическое (даже если отдельные пункты чеклиста сами по себе разумны и для каких-то случаев применимы)

Это уже где-то в нетехнической плоскости. У любого персонажа с саппорте в подписи есть контакты его менеджера. Можешь не объяснять а попросить (аргументированно) о замене. Возможно, с новым тебе повезет больше

[trud]

Цитата:

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

"Прямо сейчас" - обновление статистики (сбросив закешированный план), сохранить план и в фоне разбираться с тем, что протухло. Чинить - в AOT (индекс который должен подбираться даже при тестировании с "плохим" значением параметра, либо код).

В целом да, это собственно совпадает с тем что я написал. Кстати для тестирования очень рекомендую утилиту Дениса Сухотина - https://github.com/denissukhotin/MSS...ToSpExecuteSql, незаменимая вещь
Но join с InventDim как правило невозможно починить индексами или кодом без глобальных переделок, тут сама архитектура такая. Возьмите пример из поста - что тут можно проиндексировать? по всем полям в WHERE уже есть индексы, InventDim большая таблица

SELECT A.* FROM INVENTITEMPRICE A WHERE ((A.DATAAREAID=@P1) AND (((A.ITEMID=@P2) AND (A.PRICETYPE=@P3)) AND (A.ACTIVATIONDATE>@P4))) AND EXISTS (SELECT ''x'' FROM INVENTDIM B WHERE ((B.DATAAREAID=@P5) AND ((B.INVENTDIMID=A.INVENTDIMID) AND (B.INVENTSITEID=@P6)))) ORDER BY A.DATAAREAID,A.ACTIVATIONDATE,A.CREATEDDATETIME DESC

[Vadik]

Цитата:

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

Возьмите пример из поста - что тут можно проиндексировать? по всем полям в WHERE уже есть индексы, InventDim большая таблица

Не знаю на какой Вы версии (возможно 2009). В D365 (10.0.10) напрашивается индекс на InventItemPrice(ItemId, PriceType, ActivationDate, InventDimId)

Я бы даже создал два: {ItemId, PriceType, ActivationDate, InventDimId} и {ItemId, ActivationDate, PriceType, InventDimId}, задеплоил в sandbox и посмотрел статистику использования через пару дней

P.S. Сайтов у нас один или больше одного?
P.P.S. Кстати, хороший пример того как распределение данных и соответственно планы исполнения вполне себе могут меняться со временем. InventItemPrice ("активная" + "неактивная" себестоимость) может расти достаточно быстро (быстрее InventDim), а по стандартным индексам SEEK по "активной" ее части невозможен. Так что возможно в данном случае "классического" parameter sniffing и нет как такового, просто индексация кривая и это рано или поздно всплыло бы

[trud]

Цитата:

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

Не знаю на какой Вы версии (возможно 2009). В D365 (10.0.10) напрашивается индекс на InventItemPrice(ItemId, PriceType, ActivationDate, InventDimId)

Я бы даже создал два: {ItemId, PriceType, ActivationDate, InventDimId} и {ItemId, ActivationDate, PriceType, InventDimId}, задеплоил в sandbox и посмотрел статистику использования через пару дней

Там порядка 5 сайтов, у каждого по 5-10 цен
Я описывал 2009, но схема данных на первый взгляд такая же. Индекс ItemIdx кластерный, поэтому врядли другие в этом случае будут браться, т.е. надо менять именно его(передвигать InventDimId). При этом я не поручусь что это не затронет чего-то другого(т.е. опять надо наблюдать)
Ну т.е. в целом да, это оптимальный способ действий, если у вас есть актуальная копия рабочей бд и возможность смотреть пару дней.
В консалтинге это будет сложно продать
Совсем неправильный путь - это к примеру запустить сбор статистики или переиндексацию и сказать что все нормально

[fed]

Цитата:

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

Ну так где рекомендация-то? Я вижу список вещей которые можно попробовать, но никак не пошаговый план действий

As a first step… try to tune expensive code / queries
• Add/change indexes
• Increase selectivity
• Add hints
• Rebuild indexes
• Update statistics
• Apply other code changes (e.g. change pattern)

Т.е. мы приписываем автору что-то, чего он не заявлял, и на этом основании строим свои дальнейшие умозаключения. Удобно

Понимаешь, на самом деле надо не пробовать, а для начала посмотреть кэш планов запросов и для самых тяжелых запросов посмотреть на сами планы запросов и попытаться понять что там не так. После этого уже можно принимать осмысленные решения - сам запрос менять, дополнительные индексы строить, попробовать статистику обновлять или еще чего-то делать.
Сам по себе подход "можно попробовать", наводит на мысль что этот документ родился из алгоритма так называемого "checklist tuner". Это такой персонаж, туповатый, но самоуверенный, и как правильно титульной (для микрософта) национальности, который "разбирается" с твоими проблемами производительности, заставляя тебя выполнять все шаги из его чеклиста. И попытки ему как-то объяснить что в случае проблем со сводным планированием чистить таблицы SalesParm*/PurchParm* несколько странно, к особым результатам не приводят. (Кстати -даже странно что рекомендация чистить таблицы параметров пропущена из этого замечательного документа). Соответственно - отношение ко всем этим чеклистам у меня исключительно скептическое (даже если отдельные пункты чеклиста сами по себе разумны и для каких-то случаев применимы).