Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 кто-то плотно разбирался с "optimize for ad hoc workloads"?  [new]
Crimean
Member

Откуда:
Сообщений: 13147
что "раскопал" - действительно существенно реже компилит AQ запросы
то есть экономия на по CPU должна быть + меньше наведенных локов от этого
скажем, оконный броузинг, запросы типовые, но параметры - разные каждый раз
если включить - кеш статичный
если не включать - каждый запрос пополняет кеш планов

побочный эффект может быть неприятный - если в кеше засядет "плохой" план. он засядет надолго с этой опцией
но выигрыш, внешне, того стоит, хотя и не на всех системах будет явно виден
3 мар 12, 21:20    [12189225]     Ответить | Цитировать Сообщить модератору
 Re: кто-то плотно разбирался с "optimize for ad hoc workloads"?  [new]
Crimean
Member

Откуда:
Сообщений: 13147
если интересно - картинки насыплю :)
3 мар 12, 22:20    [12189453]     Ответить | Цитировать Сообщить модератору
 Re: кто-то плотно разбирался с "optimize for ad hoc workloads"?  [new]
Geep
Member

Откуда: Москва
Сообщений: 975
интересно!
3 мар 12, 23:00    [12189647]     Ответить | Цитировать Сообщить модератору
 Re: кто-то плотно разбирался с "optimize for ad hoc workloads"?  [new]
любитель adhoc запросов
Guest
Crimean
если интересно - картинки насыплю :)
Конечно интересно.
А ещё интересно что за картинки можно насыпать
3 мар 12, 23:00    [12189648]     Ответить | Цитировать Сообщить модератору
 Re: кто-то плотно разбирался с "optimize for ad hoc workloads"?  [new]
Crimean
Member

Откуда:
Сообщений: 13147
берем профайлер. берем "типовые" запросы на подчитку данных. скажем, так:

			using (SqlConnection con = new SqlConnection())
			{
				con.ConnectionString = string.Format("server={0};database={1};Connect Timeout=10;Application Name=CA4;Persist Security Info=false;Integrated Security=SSPI;", ".\\R2", "master");
				con.Open();

				for (int i = 0; i < 100; i++)
				{
					using (SqlCommand cmd = new SqlCommand())
					{
						cmd.Connection = con;
						cmd.CommandText = string.Format("select top 10 * from sysobjects where id > {0} order by id", i);

						using (SqlDataReader reader = cmd.ExecuteReader())
						{
							while (reader.Read())
							{
							}
						}
					}
				}
			}


пускаем профайлер на ловлю SP:CacheInsert
видим в трасе 100 записей на добавление AQ - все логично
теперь ставим 'optimize for ad hoc workloads' = 1
перед выполнением можно сбросить кеша. тогда будет 1 запись. если не сбрасывать - будет 0 записей (если до того запускали предыдущий вариант)

PROFIT

демонстрировать как борьба за кеш при достатке ресурсов убивает сервер тут не буду, но это действительно случается
штука достаточно специфичная и имеет сайд - эффекты, но попробовать стоит, если это "ваша" ситуация
ессно, не относится к RPC вызовам, что и отражено в доке
5 мар 12, 14:08    [12196005]     Ответить | Цитировать Сообщить модератору
 Re: кто-то плотно разбирался с "optimize for ad hoc workloads"?  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Правильно ли я понимаю, это костыль специально только для обхода плохого (дырявого) проектирования клиента.
5 мар 12, 16:17    [12197475]     Ответить | Цитировать Сообщить модератору
 Re: кто-то плотно разбирался с "optimize for ad hoc workloads"?  [new]
Crimean
Member

Откуда:
Сообщений: 13147
а где тут "дырявость"?
5 мар 12, 16:26    [12197571]     Ответить | Цитировать Сообщить модератору
 Re: кто-то плотно разбирался с "optimize for ad hoc workloads"?  [new]
SamMan
Member

Откуда: Moscow
Сообщений: 759
Crimean
побочный эффект может быть неприятный - если в кеше засядет "плохой" план. он засядет надолго с этой опцией


Хмм... А не менее плохой план БЕЗ этой опции засядет НЕ на долго?? Поясните, не улавливаю мысль!
5 мар 12, 17:34    [12198380]     Ответить | Цитировать Сообщить модератору
 Re: кто-то плотно разбирался с "optimize for ad hoc workloads"?  [new]
Crimean
Member

Откуда:
Сообщений: 13147
чего проще - пускаем профайлер и гоняем тестовые запросы, отличающиеся, скажем, незначащим пробелом в хвосте запроса
я уже молчу про параметризацию
5 мар 12, 17:40    [12198427]     Ответить | Цитировать Сообщить модератору
 Re: кто-то плотно разбирался с "optimize for ad hoc workloads"?  [new]
pardon
Guest
наверное чего-то не понимаю...
почему и куда костыль?
если не включать 'optimize for ad hoc workloads', все планы попадают в кэш.
если включать, то на первый раз выполнения запроса в кэш попадает не план, а stub,
у которого меньше размер и сидит он в кэше чтоб было известно, что такой-то запрос 1 раз уже выполняли.
если приходит второй раз такой же запрос, то уже в кэш запишется и план.
при чем тут вытесняемость?
что при включенной опции, что без, как вытеснялись, так и будут вытесняться.

идеализированно: если известно, что все запросы одноразовые, то надо включать, потому что вместо планов будут только stub-ы, т.е. экономия места.
с другой стороны, если все запросы хотя бы по 2 раза будут выполняться, то не надо включать, т.к. план вместо того чтоб сразу попасть, как при выключенной опции, будет дожидаться, когда у stub-а счетчик станет 2. тогда план запишется, ну т.е. сервер его 2 раза высчитает, прежде чем в кэше запомнить
5 мар 12, 17:51    [12198544]     Ответить | Цитировать Сообщить модератору
 Re: кто-то плотно разбирался с "optimize for ad hoc workloads"?  [new]
Crimean
Member

Откуда:
Сообщений: 13147
pardon,

а если "одинаковых" запросов много, но отличаются они только параметрами?
про forced пока не говорим
5 мар 12, 17:55    [12198572]     Ответить | Цитировать Сообщить модератору
 Re: кто-то плотно разбирался с "optimize for ad hoc workloads"?  [new]
pardon
Guest
Crimean,

когда нету насильной параметризации, а запрос с равенством (where id = 1),
то при включенном 'optimize for ad hoc workloads' при первом запуске запроса в кэш идет stub для shell-а (ну, который с конкретной цифрой, where id = 1),
а его настоящий план, который с параметром (сделанный сервером, where id = @1),
сразу попадает как Compiled Plan.
при запуске с другой цифрой (where id = 2) в кэш добавляется еще 1 stub для shell-а (where id = 2),
а счетчик у настоящего плана, который параметризован, увеличивается (его использовали).
теперь если снова запустить с where id = 1, вместо stub для него пишется Compiled Plan, для shell.

ну и если теперь гонять с where id = 1, то используется Compiled Plan where id = 1, и его счетчик растет.
но до тех пор, пока для дригих конкретных цифр в не запустят запрос 2 раза,
используется параметризованный Compiled Plan, а с цифрой попадает только stub.

у меня для простецкого запроса stub занимает 232 bytes,
shell 24576
а настоящий параметризованный 40960
5 мар 12, 19:12    [12199135]     Ответить | Цитировать Сообщить модератору
 Re: кто-то плотно разбирался с "optimize for ad hoc workloads"?  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Crimean
а где тут "дырявость"?
Crimean
string.Format("select top 10 * from sysobjects where id > {0} order by id", i)
Запрос должен быть константой, остальное параметрами. А тут помесь запроса и данных. Это дырявость.
Во всех нормальных конторах за такое отрывают не только руки, но и яйца, и гонят в шею на колыму с занесением в чёрный список всех родственников до 12 колена.

Или тема не раскрыта, или это костыль для говнопроектов (а их не менее чем половина).
6 мар 12, 13:54    [12203057]     Ответить | Цитировать Сообщить модератору
 Re: кто-то плотно разбирался с "optimize for ad hoc workloads"?  [new]
Crimean
Member

Откуда:
Сообщений: 13147
Mnior,

это же тест который показывает "стабильный" запрос батчем (не параметризованный и не rpc) но с меняющимися значениями параметров
6 мар 12, 16:34    [12204837]     Ответить | Цитировать Сообщить модератору
 Re: кто-то плотно разбирался с "optimize for ad hoc workloads"?  [new]
Crimean
Member

Откуда:
Сообщений: 13147
и - да - каноническая формулировка для показания доли говнопроектов в общей массе - "чуть менее, чем все"
6 мар 12, 16:36    [12204867]     Ответить | Цитировать Сообщить модератору
 Re: кто-то плотно разбирался с "optimize for ad hoc workloads"?  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Ну тада слова "кто-то плотно разбирался с ..." в заголовке темы явно не актуальны. У гуру таких проблем должно быть поменьше.
6 мар 12, 20:56    [12206567]     Ответить | Цитировать Сообщить модератору
 Re: кто-то плотно разбирался с "optimize for ad hoc workloads"?  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
pardon,
Либо я не понял, либо что за стаб пишется в кэш планов???
"в кэш попадает не план, а stub," - че за?
6 мар 12, 21:19    [12206630]     Ответить | Цитировать Сообщить модератору
 Re: кто-то плотно разбирался с "optimize for ad hoc workloads"?  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
pardon,

Прочитал тут. Теперь понял, что за "стаб", в смысле заглушка! Т.е. хранится версия экономится место, но я всерно не понял, как это согласуется с темой что поднял ТС...где там про экономию памяти на стабах вместо планов, в первое выполнение?
6 мар 12, 21:50    [12206718]     Ответить | Цитировать Сообщить модератору
 Re: кто-то плотно разбирался с "optimize for ad hoc workloads"?  [new]
Crimean
Member

Откуда:
Сообщений: 13147
SomewhereSomehow,

с загрузкой CPU и конкуренцией при парсинге еще вопросы - для этого и тему создал, времени нет детально погонять + воспроизводить не так однозначно выходит
а по памяти при "одноразовых" запросах все просто и описано в доке, вот легко воспроизводимые данные:

pardon
у меня для простецкого запроса stub занимает 232 bytes,
shell 24576
а настоящий параметризованный 40960


при сложных запросах (или тяжелых представлениях) разница будет еще больше
6 мар 12, 22:22    [12206805]     Ответить | Цитировать Сообщить модератору
 Re: кто-то плотно разбирался с "optimize for ad hoc workloads"?  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
Crimean,

Дело в том, что при любых запросах и представлениях, оптимизатор строит не "стаб" (прости Господи), а нормальный план, и все ресурсы требуемые для этого он задействует, и цпу и память и т.д., другое дело "что" он сохранит "для потомков", т.е. для будущих таких же запросов - тут я врать не буду, не тестил, стаб, так стаб. Но экономия тут выходит, только за счет памяти для кэша, и только если запросы реально не повторяются более чем один. В иных случаях, лично я - прошу доказательств, ибо не верю также как в выборы =) И выгода за счет памяти в современных системах не так уж велика, видимо именно по этому - тема не раскрыта.
6 мар 12, 22:36    [12206846]     Ответить | Цитировать Сообщить модератору
 Re: кто-то плотно разбирался с "optimize for ad hoc workloads"?  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
В смысле, тема не раскрыта в интернетах. Иначе давно б уже было стабы/планы и т.д.
6 мар 12, 22:39    [12206855]     Ответить | Цитировать Сообщить модератору
 Re: кто-то плотно разбирался с "optimize for ad hoc workloads"?  [new]
Crimean
Member

Откуда:
Сообщений: 13147
опять же, с картинкой
с памятью более-менее
остальное пока предмет для изучения

К сообщению приложен файл. Размер - 47Kb
6 мар 12, 22:41    [12206861]     Ответить | Цитировать Сообщить модератору
 Re: кто-то плотно разбирался с "optimize for ad hoc workloads"?  [new]
Crimean
Member

Откуда:
Сообщений: 13147
в продакшене стабов 26056, планов 7589. память, занятая планам меряется гигами. так что местами вполне себе имеет смысл
3 апр 12, 13:56    [12357001]     Ответить | Цитировать Сообщить модератору
 Re: кто-то плотно разбирался с "optimize for ad hoc workloads"?  [new]
squid
Member

Откуда: LA
Сообщений: 590
pardon
наверное чего-то не понимаю...
почему и куда костыль?
если не включать 'optimize for ad hoc workloads', все планы попадают в кэш.
если включать, то на первый раз выполнения запроса в кэш попадает не план, а stub,
у которого меньше размер и сидит он в кэше чтоб было известно, что такой-то запрос 1 раз уже выполняли.
если приходит второй раз такой же запрос, то уже в кэш запишется и план.
при чем тут вытесняемость?
что при включенной опции, что без, как вытеснялись, так и будут вытесняться.

идеализированно: если известно, что все запросы одноразовые, то надо включать, потому что вместо планов будут только stub-ы, т.е. экономия места.
с другой стороны, если все запросы хотя бы по 2 раза будут выполняться, то не надо включать, т.к. план вместо того чтоб сразу попасть, как при выключенной опции, будет дожидаться, когда у stub-а счетчик станет 2. тогда план запишется, ну т.е. сервер его 2 раза высчитает, прежде чем в кэше запомнить



Я попал на эту тему. Есть приложение многопоточное (C#), отсылающее однотипны запросы к БД. Все бы ничего, если не параметры типа стринг. Есно, возможные вариации комбинаций длин параметров приводили к загаживанию кеша планов. И виноват в это FW, любой версии до 4.0. В интернете на эту тему мало топиков.
Я смог решить свою проблему путем перехода на FW 4.0
Так что виноват в этом "клиент"
3 апр 12, 15:40    [12358123]     Ответить | Цитировать Сообщить модератору
 Re: кто-то плотно разбирался с "optimize for ad hoc workloads"?  [new]
stavgreengo
Member

Откуда:
Сообщений: 710
озадачился вопросом о необходимости включения данного параметры для оптимизации работы сервера БД 1С, подскажите какие счётчики надо мониторить чтобы прийти к логичному умозаключению о надобности\не надобности данного параметра при работе сервера. Счётчика использования планов обслуживания в буферном кэше нету(или я был невнимателен, если упустил, поправьте ?). Читал вот эту статью http://blog.sqlauthority.com/2009/03/21/sql-server-200ptimize-for-ad-hoc-workloads-advance-performance-optimization/ рекомендуют включать данную опцию, собственно с описанным там согласен полностью. Интересует конкретика в плане организации запросов в 1С, много ли запросов с разовыми планами выполнения ?
16 авг 12, 16:52    [13021944]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить