Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / Microsoft SQL Server |
![]() ![]() |
Idol_111 Member Откуда: Сообщений: 614 |
Неоднократно сталкивался, что Query Store (QS) серьезно переходит лимит по размеру. Скажем установленно 2Гб, а он в легкую разбухает до 5Гб. И вроде бы ничего страшного если бы после этого он не начинал чиститься ну очень долго (и как обычно не во время). И при этом потребляет до 30-50% CPU. И самое противное, что этот процесс не остановить, т.к. чистка происходит под системыми сессиями (<50) и убивать такую сессию как то не с руки. В течение этого процесса (если точнее сам процесс чистки состоит из нескольких подпроцессов, тут четкости от Майрософта нет) что либо (к примеру перевод в оффлайн или удаление всех данных) сделать с QS не возможно, блокируется. У кого-либо есть инфа почему лимит размера не соблюдается строго? Версия: 13.0.5337.0. |
30 авг 19, 05:19 [21960218] Ответить | Цитировать Сообщить модератору |
Критик Member Откуда: Москва / Калуга Сообщений: 34749 Блог |
Idol_111, SIZE_BASED_CLEANUP_MODE Определяет, будет ли автоматически активирована очистка, когда общий объем данных приблизится к верхней границе ограничения. Может иметь значение AUTO (по умолчанию) или OFF. |
30 авг 19, 07:56 [21960237] Ответить | Цитировать Сообщить модератору |
Idol_111 Member Откуда: Сообщений: 614 |
Критик, я не совсем понял, что вы хотели сказать. Если Вы спрашиваете в каком режиме у меня работает QS, то это AUTO в большинстве случаев. Прочитайте внимательно мой топик. |
2 сен 19, 00:14 [21961588] Ответить | Цитировать Сообщить модератору |
Idol_111 Member Откуда: Сообщений: 614 |
Это конечно, лишь мои предположения, но считаю нужным поделиться. Похоже, что чистка начинает сбоить, когда совпадают два вида чистки: по размеру и по дате. Сам процесс чистки состоит (это лишь мои догадки, т.к. документации/инфы на эту тему ноль) из нескольких подпроцессов. И при определенных условиях один тип чистки блокирует другой на довольно продолжительное время (часы). |
2 сен 19, 00:21 [21961589] Ответить | Цитировать Сообщить модератору |
Idol_111 Member Откуда: Сообщений: 614 |
единственное что смог найти близкое на эту тему. |
2 сен 19, 02:08 [21961601] Ответить | Цитировать Сообщить модератору |
Idol_111 Member Откуда: Сообщений: 614 |
Неплохая статья по теме топика с полезными ссылками. И не большая дискуссия в комментариях, проливащая свет на многие вопросы по топику. |
5 сен 19, 01:22 [21964113] Ответить | Цитировать Сообщить модератору |
Критик Member Откуда: Москва / Калуга Сообщений: 34749 Блог |
Idol_111, Я намекнул, что авточистку можно отключить |
5 сен 19, 05:11 [21964134] Ответить | Цитировать Сообщить модератору |
Danion Member Откуда: Москва Сообщений: 242 |
Включена авто очистка, срок хранения 3 дня. Но за 2 дня забиваются выделенные 10 ГБ и переходит в режим Read Only. В отчётах данных старше 3 дней нет, но и свежих (после первого достижения максимального размера) тоже нет. Чем забивается место при очистке данных старше 3 дней не ясно. Версия 17 CU17 Enterprise. Ещё раздражает, что при изменении параметров вешает цепочки блокировок. Кто-то сталкивался с подобным? |
22 ноя 19, 09:39 [22022400] Ответить | Цитировать Сообщить модератору |
Александр Гладченко Member Откуда: Сообщений: 10765 Блог |
В 2016/17 QDS - это зло, если есть возможность не использовать - не используйте. Его клинит с другими "чёрными ящиками" - FTS, AO, CDC... Если пришлось включать, под хранение выделяйте место с огроменным запасом, ну, скажем гигов 100, храните же минимум дней, плюс повключаейте все те настройки и флаги, что нагуглите... В общем, это один из элементов экстрима в головах разработчиков скуля :( ...хотя наживка очень на вид заманчивая... |
22 ноя 19, 13:15 [22022677] Ответить | Цитировать Сообщить модератору |
Владислав Колосов Member Откуда: Сообщений: 8340 |
У меня он по кругу тоже не работал, после заполнения переходил в состояние остановки сбора. Может настройки какие поковырять... |
22 ноя 19, 14:00 [22022782] Ответить | Цитировать Сообщить модератору |
Danion Member Откуда: Москва Сообщений: 242 |
Жаль конечно, возможности у него интересно расписаны и пару дней нормально то работает. Для кривых запросов, которые пока поправить нельзя - опция force plan помогает выбрать хотя бы более удачный план. А вот гигантские размеры при его возможности вешать блокировки на пользовательские запросы (при изменении параметров или обнулении истории) я не рискну ставить. Он сейчас при 10 ГБ висит минуты 2 намертво, а при 100 ГБ... |
22 ноя 19, 14:27 [22022830] Ответить | Цитировать Сообщить модератору |
Idol_111 Member Откуда: Сообщений: 614 |
Вы статьи, которые я дал, и комментарии к ним читали? Там все описанно про блокировки и как их избежать. |
||||
25 ноя 19, 01:00 [22024225] Ответить | Цитировать Сообщить модератору |
Idol_111 Member Откуда: Сообщений: 614 |
Не согласен. В слепую ставить конечно нельзя, но вещь крайне эффективная. Как везде и написанно, наиболее опасно ставить где куча запросов ad-hoc. Нельзя доводить систему до состояния, когда ей надо чиститься из-за переполнения по размеру, по дате - без проблем. Именно когда она начинает чиститься по размеру и происходят блокировки (см. статьи наверху) при попытке чего-то изменить. В этом случае ее трогать нельзя. Опишу один мой случай, который показывает все это в красках. Терабайтная OLTP база, к которой обращение в основном типа ad-hoc. К тому же какие-то уроды закодили часть параметров прямо в скрипт. Т.е. для сервера это каждый раз разные запросы, и они тяжелые, т.е. попадают в QS. Максимально удавалось хранить 3-4 дня и занимало это все до 12Гб и около 700000 запросов. После продолжительных баданий разработчик пофиксил лишь один запрос (на котором я настаивал). Итог: размер рухнул до 30Мб, 30000 запросов. И после этого уже смог увеличить хранение до месяца при стабильном размере 3Гб. QS очень помогает оперативно привести в чувство тяжелый запросы, используя force plan. Грузит сервер менее 1%. Короче, не нарадуюсь. Это еще без статистики, т.к. пока на 2016. |
||||
25 ноя 19, 01:22 [22024229] Ответить | Цитировать Сообщить модератору |
Idol_111 Member Откуда: Сообщений: 614 |
хотел написать - без ожиданий. |
||||
25 ноя 19, 01:41 [22024231] Ответить | Цитировать Сообщить модератору |
Danion Member Откуда: Москва Сообщений: 242 |
Idol_111, Ссылки смотрел: Yes, Query Store can struggle in an ad hoc workload. Changing ANY Query Store requires a lock over the Query Store database object, which can block other Query Store background tasks over that database. So yes, any changes should be made when the system is not busy, and yes, you should have the catpure mode set to AUTO. Там как раз написано, что такие блокировки данность хранилища и с ними ничего не сделаешь. Рекомендация производить изменения при минимуме нагрузки. |
25 ноя 19, 09:52 [22024332] Ответить | Цитировать Сообщить модератору |
a_voronin Member Откуда: Москва Сообщений: 4807 |
Может стоит поработать над параметризацией запросов |
25 ноя 19, 10:12 [22024353] Ответить | Цитировать Сообщить модератору |
Danion Member Откуда: Москва Сообщений: 242 |
a_voronin, Это да, как и у Idol_111 есть одни и те же запросы, которые сервер считает разными. Сейчас проверил - часть запросов о которых писал разработчики поправили, часть нет. |
25 ноя 19, 10:19 [22024365] Ответить | Цитировать Сообщить модератору |
Idol_111 Member Откуда: Сообщений: 614 |
Это не данность хранилища. Это косяк/особенность процесса чистки по размеру. Этот процесс может занимать слишком много времени (часы), и лишь это проблема - длительность этого процесса. Смотреть надо лишь на подобную команду:
Если оно висит, то трогать QS бесполезно. Какая при этом нагрузка без разницы. Сообщение было отредактировано: 25 ноя 19, 23:09 |
|||||||||||||
25 ноя 19, 23:07 [22025087] Ответить | Цитировать Сообщить модератору |
Александр Гладченко Member Откуда: Сообщений: 10765 Блог |
Idol_111, https://blogs.msmvps.com/gladchenko/query-store-background-flush-db/ |
25 ноя 19, 23:56 [22025114] Ответить | Цитировать Сообщить модератору |
Idol_111 Member Откуда: Сообщений: 614 |
Эх, где ж Вы раньше были :) , в июле августе. Помню пробовал что-то делать с SET DEADLOCK_PRIORITY HIGH, но детали уже не упомню. У меня не сработало. Сообщение было отредактировано: 26 ноя 19, 02:24 |
||||
26 ноя 19, 02:21 [22025147] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31782 |
|
||||
26 ноя 19, 06:53 [22025165] Ответить | Цитировать Сообщить модератору |
Danion Member Откуда: Москва Сообщений: 242 |
Idol_111, "Это не данность хранилища. Это косяк/особенность процесса чистки по размеру. Этот процесс может занимать слишком много времени (часы), и лишь это проблема - длительность этого процесса." Так я не про блокировки во время очистки по размеру. Эта очистка вообще не хочет работать. У меня любое изменение параметров хранилища вызывает блокировки. Большинство короткие, типа увеличить размер хранилища, увеличить срок хранения. А вот отключение чистки по размеру где-то минуты на 3 всё повесило. Пока оставлю сбор данных включенным и буду смотреть в сторону уменьшения количества запросов с разницей в переменной. |
26 ноя 19, 09:24 [22025220] Ответить | Цитировать Сообщить модератору |
Idol_111 Member Откуда: Сообщений: 614 |
|
||||||||
28 ноя 19, 00:57 [22027136] Ответить | Цитировать Сообщить модератору |
Idol_111 Member Откуда: Сообщений: 614 |
тут я не понял.
А это не нормально. Никогда не встречал чтобы кто-нибудь жаловался на это. Вы проверьте, что блокирует и тогда будет что обсудить. |
||||||||
28 ноя 19, 01:00 [22027138] Ответить | Цитировать Сообщить модератору |
Все форумы / Microsoft SQL Server | ![]() |