Неоднократно сталкивался, что Query Store (QS) серьезно переходит лимит по размеру. Скажем установленно 2Гб, а он в легкую разбухает до 5Гб. И вроде бы ничего страшного если бы после этого он не начинал чиститься ну очень долго (и как обычно не во время). И при этом потребляет до 30-50% CPU.
И самое противное, что этот процесс не остановить, т.к. чистка происходит под системыми сессиями (<50) и убивать такую сессию как то не с руки. В течение этого процесса (если точнее сам процесс чистки состоит из нескольких подпроцессов, тут четкости от Майрософта нет) что либо (к примеру перевод в оффлайн или удаление всех данных) сделать с QS не возможно, блокируется.

У кого-либо есть инфа почему лимит размера не соблюдается строго?

Версия: 13.0.5337.0.

Критик,

я не совсем понял, что вы хотели сказать. Если Вы спрашиваете в каком режиме у меня работает QS, то это AUTO в большинстве случаев.
Прочитайте внимательно мой топик.

Это конечно, лишь мои предположения, но считаю нужным поделиться.

Похоже, что чистка начинает сбоить, когда совпадают два вида чистки: по размеру и по дате.
Сам процесс чистки состоит (это лишь мои догадки, т.к. документации/инфы на эту тему ноль) из нескольких подпроцессов. И при определенных условиях один тип чистки блокирует другой на довольно продолжительное время (часы).

единственное что смог найти близкое на эту тему.

Неплохая статья по теме топика с полезными ссылками.
И не большая дискуссия в комментариях, проливащая свет на многие вопросы по топику.

Вы статьи, которые я дал, и комментарии к ним читали?
Там все описанно про блокировки и как их избежать.

Не согласен. В слепую ставить конечно нельзя, но вещь крайне эффективная.

Как везде и написанно, наиболее опасно ставить где куча запросов ad-hoc.
Нельзя доводить систему до состояния, когда ей надо чиститься из-за переполнения по размеру, по дате - без проблем.
Именно когда она начинает чиститься по размеру и происходят блокировки (см. статьи наверху) при попытке чего-то изменить. В этом случае ее трогать нельзя.

Опишу один мой случай, который показывает все это в красках.
Терабайтная OLTP база, к которой обращение в основном типа ad-hoc. К тому же какие-то уроды закодили часть параметров прямо в скрипт. Т.е. для сервера это каждый раз разные запросы, и они тяжелые, т.е. попадают в QS.
Максимально удавалось хранить 3-4 дня и занимало это все до 12Гб и около 700000 запросов.
После продолжительных баданий разработчик пофиксил лишь один запрос (на котором я настаивал). Итог: размер рухнул до 30Мб, 30000 запросов. И после этого уже смог увеличить хранение до месяца при стабильном размере 3Гб.

QS очень помогает оперативно привести в чувство тяжелый запросы, используя force plan.
Грузит сервер менее 1%.

Короче, не нарадуюсь. Это еще без статистики, т.к. пока на 2016.

хотел написать - без ожиданий.

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

Смотреть надо лишь на подобную команду:
Task State Command Total CPU (ms) Elapsed Time (in Sec)RUNNING QUERY STORE SIZE BASED CLEANUP 28860185 32304.432000
Если оно висит, то трогать QS бесполезно.
Какая при этом нагрузка без разницы.

Эх, где ж Вы раньше были :) , в июле августе.

Помню пробовал что-то делать с SET DEADLOCK_PRIORITY HIGH, но детали уже не упомню. У меня не сработало.

Александр просто привел вариант, как можно убить чистку по размеру без перезагрузки сервера.

тут я не понял.

А это не нормально. Никогда не встречал чтобы кто-нибудь жаловался на это.
Вы проверьте, что блокирует и тогда будет что обсудить.