| Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
| Все форумы / Microsoft SQL Server |
  |
||
| Топик располагается на нескольких страницах: [1] 2 вперед Ctrl→ все |
 Рост производительности после изменения размера выделеной SQLю памяти
|
|
|
Vladka12 Member Откуда: Сообщений: 17 |
Есть выделенный сервер для баз 1С 8.2.19.83 на MS SQL 2008 r2 (Microsoft SQL Server Standard Edition (64-bit) 10.50.4266.0). Там живут всего две базы примерно по 400 гиг - бухгалтерия и управленка По окончании рабочего дня, агентом выполняются задачи обслуживания: бзкапы(фул) и выборочное обновление индексов/статистик в зависимости от уровня фрагментации. За ними стартуют 1С задания- в основном перепроведение документов. Так вот собственно проблема - перепроведение в 1С выполняется медленно при вполне незагруженном сервере (до 10% по процу и диску, очереди запросов тоже небольшие ) Но замечено что производительность растет после изменения max memory size. ПРмчем изменение можно делать в любую сторону и незначительное по величине (с 60 на 61 Гиг или обратно ). Со стороні 1С аплткейшн сервера в это время просто продолжается процесс перепроведения. Я конечно уже внес в задвния агента изменять память (на старте и финише заданий обслуживания). Но может кто-то сталкивался с подобным явлением и может подсказать как исправить ситуацию и почему такое может происходить? |
| 22 июн 15, 13:33 [17801853] Ответить | Цитировать Сообщить модератору | |
| Re: Рост производительности после изменения размера выделеной SQLю памяти
|
|
|
Oleksii Kovalov Member Откуда: Сообщений: 100 |
М.б. накапливаются "плохие" планы запросов, а изменение объема выделенной памяти сбрасывает кэш планов. если это так, то dbcc freeproccache может вам помочь Им же, кстати, можно и проверить - правда ли это так |
| 22 июн 15, 13:50 [17801935] Ответить | Цитировать Сообщить модератору | |
| Re: Рост производительности после изменения размера выделеной SQLю памяти
|
|
|
Vladka12 Member Откуда: Сообщений: 17 |
Oleksii Kovalov, спасибо но нет. Кеш планов жив а сброс его приводит к замедлению работы перепроведения примерно на полчаса. Проверял по настоянию 1с-ников на тесте. К тому же изменение статистики должно по идее приводить к устареванию планов относительно объектов с изиенившейся (пересчитаной) статистикой |
| 22 июн 15, 14:03 [17801999] Ответить | Цитировать Сообщить модератору | |
| Re: Рост производительности после изменения размера выделеной SQLю памяти
|
|
|
Basma4 Member Откуда: Сообщений: 124 |
Vladka12, я бы понаблюдал за PLE какие значения до измения и после и во время проведения., да и вообще за использованием ОЗУ. и вот это глянул бы SQLServer:Plan Cashe/Cashe objects counts SQLServer:Plan Cashe/Cashe objects in use |
| 22 июн 15, 17:07 [17802880] Ответить | Цитировать Сообщить модератору | |
| Re: Рост производительности после изменения размера выделеной SQLю памяти
|
|
|
Vladka12 Member Откуда: Сообщений: 17 |
Basma4, Спасибо, интересно. Увижу завтра во время выполнения регламентных работ. |
| 22 июн 15, 20:26 [17803539] Ответить | Цитировать Сообщить модератору | |
| Re: Рост производительности после изменения размера выделеной SQLю памяти
|
|
|
Vladka12 Member Откуда: Сообщений: 17 |
Basma4, Вот и сюрприз ПРи увеличении max memory size , Cache Object сounts SQL Plans упало к нулю ю. Т.е. сбросился, тогда в чем отличие от DBCC FREEPROCCACHE. Но после очистки кэша была просадка по производительности!! с PLE вроде все нори - порядка 6000 и от размера памяти не меняется |
| 22 июн 15, 23:08 [17804182] Ответить | Цитировать Сообщить модератору | |
| Re: Рост производительности после изменения размера выделеной SQLю памяти
|
|||||
|
Mind Member Откуда: Лучший город на Земле Сообщений: 2322 |
|
||||
| 22 июн 15, 23:14 [17804212] Ответить | Цитировать Сообщить модератору | |||||
| Re: Рост производительности после изменения размера выделеной SQLю памяти
|
|
|
Mind Member Откуда: Лучший город на Земле Сообщений: 2322 |
Vladka12, Может у вас вся память занята кешем планов, а когда он сбрасывается появляется свободная память и сервер начинает шустрее работать. |
| 22 июн 15, 23:21 [17804249] Ответить | Цитировать Сообщить модератору | |
| Re: Рост производительности после изменения размера выделеной SQLю памяти
|
|
|
Vladka12 Member Откуда: Сообщений: 17 |
Всем спасибо ! Продолжу тесты завтра - для чистоты |
| 23 июн 15, 00:04 [17804456] Ответить | Цитировать Сообщить модератору | |
| Re: Рост производительности после изменения размера выделеной SQLю памяти
|
|
|
Oleksii Kovalov Member Откуда: Сообщений: 100 |
Еще можно посмотреть в сторону parametrization forced Вдруг поможет |
| 23 июн 15, 01:17 [17804544] Ответить | Цитировать Сообщить модератору | |
| Re: Рост производительности после изменения размера выделеной SQLю памяти
|
|||
|
Владислав Колосов Member Откуда: Сообщений: 8489 |
Перепроведение совпадает с бэкапом по времени? Т.е. бэкап завершается к моменту обработки данных или нет? |
||
| 23 июн 15, 11:34 [17805598] Ответить | Цитировать Сообщить модератору | |||
| Re: Рост производительности после изменения размера выделеной SQLю памяти
|
|
|
Vladka12 Member Откуда: Сообщений: 17 |
Владислав Колосов, По времени бэкап и перепроведение обычно не совпадают. |
| 23 июн 15, 14:07 [17806744] Ответить | Цитировать Сообщить модератору | |
| Re: Рост производительности после изменения размера выделеной SQLю памяти
|
|
|
Владислав Колосов Member Откуда: Сообщений: 8489 |
Vladka12, для 1С базы попробуйте ALTER DATABASE ... SET PARAMETERIZATION FORCED. Через пару дней должен появиться положительный эффект, если не будете чистить кэш или рестартовать сервис. Однако, не уверен, что 2008 R2 поддерживает настройку. |
| 23 июн 15, 14:48 [17806946] Ответить | Цитировать Сообщить модератору | |
| Re: Рост производительности после изменения размера выделеной SQLю памяти
|
|||
|
o-o
Guest |
не надо в 2008-ом сомневаться, он поддерживает. я больше сомневаюсь в проявлении положительного эффекта |
||
| 23 июн 15, 14:59 [17807030] Ответить | Цитировать Сообщить модератору | |||
| Re: Рост производительности после изменения размера выделеной SQLю памяти
|
|
|
Basma4 Member Откуда: Сообщений: 124 |
я бы поставил optimize for ad hoc workloads=1 ибо 1С=ad hoc workloads если бы ТС показал значение SQLServer:Plan Cashe/Cashe objects counts SQLServer:Plan Cashe/Cashe objects in use можно было бы увидеть что 1С очень мало использут повторно планы и часто компилирует их по новой даже при условии что запрос одинаковый и с одинаковыми параметрами (только различаются название временных таблиц). |
| 23 июн 15, 15:05 [17807070] Ответить | Цитировать Сообщить модератору | |
| Re: Рост производительности после изменения размера выделеной SQLю памяти
|
|
|
Владислав Колосов Member Откуда: Сообщений: 8489 |
o-o, я был тоже не уверен, по-тихому на свой риск включил, оказалось, что теперь можно отказаться от руководства планов. Т.к. одно приложение генерит AD HOC в огромных количествах (а-ля 1С). В результате кеш перестал беспредельно расти и половина adhoc переместилась в разряд компилированных. Реакция интерфейса (а он лезет в базу по малейшему чиху) значительно улучшилось. Такая вот история приключается когда используют MS persistent model. |
| 23 июн 15, 15:08 [17807094] Ответить | Цитировать Сообщить модератору | |
| Re: Рост производительности после изменения размера выделеной SQLю памяти
|
|||
|
Владислав Колосов Member Откуда: Сообщений: 8489 |
Вот это как раз бьет по производительности параметризованных запросов. Это тоже пробовал. Эта опция хороша, когда запросы не типовые и ничто другое не помогает. В этом случае просто спасаем кэш для регулярных запросов без улучшения скорости выполнения разовых. |
||
| 23 июн 15, 15:11 [17807115] Ответить | Цитировать Сообщить модератору | |||
| Re: Рост производительности после изменения размера выделеной SQLю памяти
|
|
|
Vladka12 Member Откуда: Сообщений: 17 |
согласен с o-o. Про 1С такой рекомендации не видал. Доводилось смотреть на некоторые из запросов 1ски, проблем с параметризацией не видел. С этим флагом по-экспиремнтирую позже - все-таки не вижу связи грязнргр кеша с force(сорри, но мне кажется что мусора в кэше прибавится). Если не прав - ругайте :- ) Если кто видел подобные рекомендации для 1с 8.2 прошу поделиться |
| 23 июн 15, 18:49 [17808259] Ответить | Цитировать Сообщить модератору | |
| Re: Рост производительности после изменения размера выделеной SQLю памяти
|
|||
|
Vladka12 Member Откуда: Сообщений: 17 |
да. Запросы там вроде и параметризованные, но параметров два ведра на запрос |
||
| 23 июн 15, 19:10 [17808324] Ответить | Цитировать Сообщить модератору | |||
| Re: Рост производительности после изменения размера выделеной SQLю памяти
|
|
|
Vladka12 Member Откуда: Сообщений: 17 |
dbcc freeproccache на рабочей системе вызывает повышение производительности...Проверил. Cache Objects in use больше не стало - до 10. на перфоманс мониторе разницы не видно. Откуда кривые планы? статистика обновлена, индексы дефрагментированы - по идее планы, в которых участвовали сильно изменённые таблицы, в теории считаются устаревшими .... причина непонятна |
| 23 июн 15, 22:08 [17808819] Ответить | Цитировать Сообщить модератору | |
| Re: Рост производительности после изменения размера выделеной SQLю памяти
|
|
|
Oleksii Kovalov Member Откуда: Сообщений: 100 |
Планы не столько кривые, сколько много их, похожих, но разнообразных в такой ситуации производительность снижается. опять таки - а кто сказал, что при актуальной статистике планы всегда получаются кошерными? просмотр параметров и всё такое же. зы степень фрагментации на планы не влияет |
| 23 июн 15, 22:12 [17808831] Ответить | Цитировать Сообщить модератору | |
| Re: Рост производительности после изменения размера выделеной SQLю памяти
|
|||||||
|
Vladka12 Member Откуда: Сообщений: 17 |
да, интересно что с этим можно сделать?
ну собственно после очистки новые планы работают лучше. А старые почему от новых отличаются?
если ребилд - то вроде должна? |
||||||
| 23 июн 15, 22:46 [17808915] Ответить | Цитировать Сообщить модератору | |||||||
| Re: Рост производительности после изменения размера выделеной SQLю памяти
|
|||||||
|
Oleksii Kovalov Member Откуда: Сообщений: 100 |
Очистить?
например потому что прослушивание параметров. или так "карта легла"
Неа. для того чтобы фрагментация учитывалась оптимизатором -она должна быть легко и быстро доступна. А такового нету. Да и смысл в этом, вообще говоря, сугубо академический |
||||||
| 23 июн 15, 22:49 [17808921] Ответить | Цитировать Сообщить модератору | |||||||
| Re: Рост производительности после изменения размера выделеной SQLю памяти
|
|||
|
Vladka12 Member Откуда: Сообщений: 17 |
Не совсем понялкак в этом убедиться? разговор про это: CACHESTORE_SQLCP так он вроде от max memory зависит |
||
| 23 июн 15, 22:57 [17808934] Ответить | Цитировать Сообщить модератору | |||
| Re: Рост производительности после изменения размера выделеной SQLю памяти
|
|
|
Vladka12 Member Откуда: Сообщений: 17 |
Очистить - так я и очищаю - хотелось понять, есть ли более культурные пути например потому что прослушивание параметров. или так "карта легла" -А как Вы думаете, имееи смысл рыть дальше? |
| 23 июн 15, 23:06 [17808954] Ответить | Цитировать Сообщить модератору | |
| Топик располагается на нескольких страницах: [1] 2 вперед Ctrl→ все |
| Все форумы / Microsoft SQL Server | |
|
x