Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Ухудшение производительности после апгрейда 2008R2  [new]
Idol_111
Member

Откуда:
Сообщений: 633
Апрейдил SQL2008R2 (10.50.1790) до 10.50.2769 (SP1 and CU1).
Некоторые планы запросов поменялись не в лучшую сторону.

Кто-либо сталкивался с падением производительности после апгрейда до моей версии?
22 сен 11, 02:57    [11316342]     Ответить | Цитировать Сообщить модератору
 Re: Ухудшение производительности после апгрейда 2008R2  [new]
tpg
Member

Откуда: Novosibirsk
Сообщений: 23902
Статистику не пробовали обновлять?
22 сен 11, 05:33    [11316373]     Ответить | Цитировать Сообщить модератору
 Re: Ухудшение производительности после апгрейда 2008R2  [new]
Idol_111
Member

Откуда:
Сообщений: 633
tpg
Статистику не пробовали обновлять?

Конечно, сделано.

К примеру, отловил один запрос, типа:
SELECT *
FROM view_1
INNER JOIN table_1
ON  table_1.id = view_1.id
WHERE '2011-09-20' = CONVERT(DATE,view_1.date_created,102)
ORDER BY view_1.number
если до апгрейда сервер делал поиск по view_1.date_created и еще одному параметру, забитому во вьюху, то теперь view_1.date_created фильтрует после выборки из вьюхи. Ну а в этом случае серверу нужно прочитать тонны данных из вьюхи. Итого: запрос вместо 10сек работает более 5мин.

И главное, не могу понять почему. Что его теперь не устраивает?
22 сен 11, 06:02    [11316382]     Ответить | Цитировать Сообщить модератору
 Re: Ухудшение производительности после апгрейда 2008R2  [new]
aleks2
Guest
Idol_111
tpg
Статистику не пробовали обновлять?

Конечно, сделано.

К примеру, отловил один запрос, типа:
SELECT *
FROM view_1
INNER JOIN table_1
ON  table_1.id = view_1.id
WHERE '2011-09-20' = CONVERT(DATE,view_1.date_created,102)
ORDER BY view_1.number
если до апгрейда сервер делал поиск по view_1.date_created и еще одному параметру, забитому во вьюху, то теперь view_1.date_created фильтрует после выборки из вьюхи. Ну а в этом случае серверу нужно прочитать тонны данных из вьюхи. Итого: запрос вместо 10сек работает более 5мин.

И главное, не могу понять почему. Что его теперь не устраивает?


Наверное, сервер хочет вам продемострировать ваш идиотизм, заключающийся в пренебрежении индексами.

SELECT *
FROM view_1
INNER JOIN table_1
ON  table_1.id = view_1.id
WHERE cast('20110920' as datetime) <= view_1.date_created AND view_1.date_created<DATEADD(day, 1, cast('20110920' as datetime))
ORDER BY view_1.number
22 сен 11, 06:55    [11316400]     Ответить | Цитировать Сообщить модератору
 Re: Ухудшение производительности после апгрейда 2008R2  [new]
Idol_111
Member

Откуда:
Сообщений: 633
aleks2,
Громадное спасибо, что ткнули меня носом в подобный идиотизм.
Однако, я не девелопер, а админ и подобный идиотизм не создаю, а разбираюсь с ним.

И в данном случае, меня как админа, больше волнует странное поведение сервера после апгрейда, т.к. этот запрос лишь частный случай. А ухудшение производительности отмечается повсеместно. Хорошо еще, это ухудшение заметно только мне, пока что юзеры не жалуются :).
Это не нормально, когда старый сервер умнее нового и был в состоянии исправлять ошибки разработчиков, а новый делает пшик.

Для теста, я создал новые базы данных на серверах с новой и старой версией. Залил туда таблицы, которые учавствуют в данном запросе и потестил. Проапгреденный сервер упорно не желает фильтровать данные по дате в начале, а старые делает это не напрягаясь.

Поскажите, может нужно проверить какие-либо серверные (или базы данных) настройки, которые могли измениться после апгрейда.
22 сен 11, 07:53    [11316449]     Ответить | Цитировать Сообщить модератору
 Re: Ухудшение производительности после апгрейда 2008R2  [new]
iljy
Member

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

у меня 10.50.2772 (SP1 + CU2), и я сейчас специально проверил - он умеет превращать where CAST(dt as Date) = '20100225' в поиск по диапазону. Так что проблема явно не в поглупении сервера. Выкладывайте планы, можете выложить тестовую базу, на которой запрос сваливается в сканирование.
22 сен 11, 08:38    [11316552]     Ответить | Цитировать Сообщить модератору
 Re: Ухудшение производительности после апгрейда 2008R2  [new]
эспандроид
Guest
Idol_111,

вьюха индексированная или обычная?
22 сен 11, 09:38    [11316749]     Ответить | Цитировать Сообщить модератору
 Re: Ухудшение производительности после апгрейда 2008R2  [new]
aleks2
Guest
Idol_111
aleks2,
Это не нормально, когда старый сервер умнее нового и был в состоянии исправлять ошибки разработчиков, а новый делает пшик.

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


1. Изменение поведение оптимизатора случается и не только при замене сервера. Бывалочи и обновление выносит мозг запросу. Классика жанра - SP4 для MS SQL2000.
2. Так что это дело житейское.
3. Единственный вариант - писать запросы так, чтоб у сервера не оставалось выбора.
4. Ну самое банальное - ваше соединение с новым сервером использует ДРУГИЕ SET опции.
22 сен 11, 10:18    [11316937]     Ответить | Цитировать Сообщить модератору
 Re: Ухудшение производительности после апгрейда 2008R2  [new]
Idol_111
Member

Откуда:
Сообщений: 633
iljy
Idol_111,

у меня 10.50.2772 (SP1 + CU2), и я сейчас специально проверил - он умеет превращать where CAST(dt as Date) = '20100225' в поиск по диапазону. Так что проблема явно не в поглупении сервера. Выкладывайте планы, можете выложить тестовую базу, на которой запрос сваливается в сканирование.

Я и не говорю, что сервер разучился поиску по диапозону. В варианте alexks2 новый сервер делает это без проблем.
Дело не в сканировании, а в фильтрации по дате. Новый сервер это делает в конце, старый в начале.

Это 2005 сервер:
StmtText
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
  |--Parallelism(Gather Streams, ORDER BY:([Expr1009] ASC))
       |--Nested Loops(Inner Join, WHERE:([test].[dbo].[batch].[company] as [b].[company]=[test].[dbo].[company].[company_code] as [c].[company_code]))
            |--Sort(ORDER BY:([Expr1009] ASC))
            |    |--Stream Aggregate(GROUP BY:([b].[_batch_pk]) DEFINE:([Expr1008]=MIN([partialagg1014]), [Expr1009]=MAX([partialagg1015]), [b].[company]=ANY([test].[dbo].[batch].[company] as [b].[company]), [b].[created]=ANY([test].[dbo].[batch].[created]
            |         |--Parallelism(Repartition Streams, Hash Partitioning, PARTITION COLUMNS:([b].[_batch_pk]), ORDER BY:([b].[_batch_pk] ASC))
            |              |--Stream Aggregate(GROUP BY:([b].[_batch_pk]) DEFINE:([partialagg1014]=MIN([test].[dbo].[item].[number] as [i].[number]), [partialagg1015]=MAX([test].[dbo].[item].[number] as [i2].[number]), [b].[company]=ANY([test].[dbo].[batch
            |                   |--Nested Loops(Inner Join, OUTER REFERENCES:([i].[batch_fk], [i].[number]))
            |                        |--Nested Loops(Inner Join, OUTER REFERENCES:([b].[_batch_pk], [Expr1016]) WITH ORDERED PREFETCH)
            |                        |    |--Clustered Index Scan(OBJECT:([test].[dbo].[batch].[PK_clust] AS [b]),  WHERE:([test].[dbo].[batch].[method] as [b].[method]='DRAW_CHEQUE' AND '2011-09-19 00:00:00.000'=CONVERT(datetime,(right('0000'+CONVERT(varc
            |                        |    |--Index Seek(OBJECT:([test].[dbo].[item].[ix_item_batch] AS [i]), SEEK:([i].[batch_fk]=[test].[dbo].[batch].[_batch_pk] as [b].[_batch_pk]) ORDERED FORWARD)
            |                        |--Filter(WHERE:([test].[dbo].[item].[batch_fk] as [i2].[batch_fk]<[test].[dbo].[item].[batch_fk] as [i].[batch_fk]))
            |                             |--Index Spool(SEEK:([i2].[number] < [test].[dbo].[item].[number] as [i].[number]))
            |                                  |--Index Scan(OBJECT:([test].[dbo].[item].[ix_item_batch] AS [i2]))
            |--Table Scan(OBJECT:([test].[dbo].[company] AS [c]))
Это 2008 сервер:
StmtText
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
  |--Nested Loops(Inner Join, WHERE:([test].[dbo].[batch].[company] as [b].[company]=[test].[dbo].[company].[company_code] as [c].[company_code]))
       |--Sort(ORDER BY:([Expr1009] ASC))
       |    |--Filter(WHERE:('2011-09-19 00:00:00.000'=[Expr1013]))
       |         |--Compute Scalar(DEFINE:([Expr1013]=CONVERT(datetime,(right('0000'+CONVERT(varchar(30),datepart(year,[test].[dbo].[batch].[created] as [b].[created]),0),(4))+right('00'+CONVERT(varchar(30),datepart(month,[test].[dbo].[batch].[created] as 
       |              |--Stream Aggregate(GROUP BY:([b].[_batch_pk]) DEFINE:([Expr1008]=MIN([test].[dbo].[item].[number] as [i].[number]), [Expr1009]=MAX([test].[dbo].[item].[number] as [i2].[number]), [b].[company]=ANY([test].[dbo].[batch].[company] as [b
       |                   |--Nested Loops(Inner Join, OUTER REFERENCES:([i].[batch_fk], [i].[number]))
       |                        |--Nested Loops(Inner Join, OUTER REFERENCES:([b].[_batch_pk], [Expr1016]) WITH ORDERED PREFETCH)
       |                        |    |--Clustered Index Scan(OBJECT:([test].[dbo].[batch].[PK_clust] AS [b]),  WHERE:([test].[dbo].[batch].[method] as [b].[method]='DRAW_CHEQUE') ORDERED FORWARD)
       |                        |    |--Index Seek(OBJECT:([test].[dbo].[item].[ix_item_batch] AS [i]), SEEK:([i].[batch_fk]=[test].[dbo].[batch].[_batch_pk] as [b].[_batch_pk]) ORDERED FORWARD)
       |                        |--Table Spool
       |                             |--Filter(WHERE:([test].[dbo].[item].[batch_fk] as [i2].[batch_fk]<[test].[dbo].[item].[batch_fk] as [i].[batch_fk]))
       |                                  |--Index Spool(SEEK:([i2].[number] < [test].[dbo].[item].[number] as [i].[number]))
       |                                       |--Index Scan(OBJECT:([test].[dbo].[item].[ix_item_batch] AS [i2]))
       |--Table Scan(OBJECT:([test].[dbo].[company] AS [c]))
23 сен 11, 09:38    [11323378]     Ответить | Цитировать Сообщить модератору
 Re: Ухудшение производительности после апгрейда 2008R2  [new]
Idol_111
Member

Откуда:
Сообщений: 633
эспандроид
Idol_111,

вьюха индексированная или обычная?

обычная
23 сен 11, 09:38    [11323380]     Ответить | Цитировать Сообщить модератору
 Re: Ухудшение производительности после апгрейда 2008R2  [new]
Idol_111
Member

Откуда:
Сообщений: 633
aleks2
4. Ну самое банальное - ваше соединение с новым сервером использует ДРУГИЕ SET опции.

Про SET опции не понял. Я то все тестирую ручками со студии. Разъясните пожалуйста.
23 сен 11, 09:41    [11323400]     Ответить | Цитировать Сообщить модератору
 Re: Ухудшение производительности после апгрейда 2008R2  [new]
Glory
Member

Откуда:
Сообщений: 104751
Idol_111
эспандроид
Idol_111,

вьюха индексированная или обычная?

обычная

А view_1.date_created - это же выражение в представлении ?
23 сен 11, 09:43    [11323414]     Ответить | Цитировать Сообщить модератору
 Re: Ухудшение производительности после апгрейда 2008R2  [new]
Idol_111
Member

Откуда:
Сообщений: 633
Это сам тестовый скрипт. Вьюху запихал внутрь.
(на параллелизм в первом плане можно не обращать внимания, в реале его нет. просто настройки сервера другие)

SELECT view1._batch_pk
  ,view1.created
  ,view1.lnumber
  ,c.company_name
  ,view1.number
FROM (
SELECT b._batch_pk
  ,b.company
  ,b.currency
  ,b.bank
  ,b.batch_status
  ,b.[date]
  ,b.batch_
  ,b.selected
  ,b.selected_
  ,b.updated
  ,b.updated_
  ,b.created
  ,b.created_
  ,MIN(i.number) AS number
  ,MAX(i2.number)      AS lnumber
FROM batch as b
inner join item as i
on i.batch_fk = b._batch_pk
AND b.method  = 'DRAW_CHEQUE'
inner join item as i2
on i2.number                 < i.number
AND i2.batch_fk        < i.batch_fk
GROUP BY b._batch_pk
  ,b.company
  ,b.currency
  ,b.bank
  ,b.batch_status
  ,b.[date]
  ,b.batch_
  ,b.selected
  ,b.selected_
  ,b.updated
  ,b.updated_
  ,b.created
  ,b.created_

) as view1
INNER JOIN dbo.company as c
ON  view1.company = c.company_code
--and '2011-07-20' = CONVERT(DATE,view1.created,102)
   --and view1.created >= cast('2011-09-19' as datetime) 
   --and view1.created < dateadd(day, 1, cast('2011-09-19' as datetime))
and     {d '2011-09-19'} = CONVERT(DATETIME,RIGHT('0000' + CONVERT(VARCHAR,{fn YEAR(view1.created) }),4) 
+ RIGHT('00' + CONVERT(VARCHAR,{fn MONTH(view1.created) }),2) 
+ RIGHT('00' + CONVERT(VARCHAR,{fn DAYOFMONTH(view1.created) }),2))
ORDER BY view1.lnumber
23 сен 11, 09:48    [11323451]     Ответить | Цитировать Сообщить модератору
 Re: Ухудшение производительности после апгрейда 2008R2  [new]
iljy
Member

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

не, ну вы почаще такие
CONVERT(DATETIME,RIGHT('0000' + CONVERT(VARCHAR,{fn YEAR(view1.created) }),4) 
+ RIGHT('00' + CONVERT(VARCHAR,{fn MONTH(view1.created) }),2) 
+ RIGHT('00' + CONVERT(VARCHAR,{fn DAYOFMONTH(view1.created) }),2))
вещи пишите - еще не то увидите
23 сен 11, 09:58    [11323543]     Ответить | Цитировать Сообщить модератору
 Re: Ухудшение производительности после апгрейда 2008R2  [new]
aleks2
Guest
Idol_111
aleks2
4. Ну самое банальное - ваше соединение с новым сервером использует ДРУГИЕ SET опции.

Про SET опции не понял. Я то все тестирую ручками со студии. Разъясните пожалуйста.

У подключения есть параметры SET ... . Если явно не заданы - используются установки сервера.
Эти параметры влияют на планы запросов.

Короче

DBCC USEROPTIONS

сравните.
23 сен 11, 10:27    [11323805]     Ответить | Цитировать Сообщить модератору
 Re: Ухудшение производительности после апгрейда 2008R2  [new]
Idol_111
Member

Откуда:
Сообщений: 633
aleks2
DBCC USEROPTIONS

сравните.

Сервера идентичны. По крайней мере апгрейд сервера эти установки не понял.
26 сен 11, 03:09    [11334499]     Ответить | Цитировать Сообщить модератору
 Re: Ухудшение производительности после апгрейда 2008R2  [new]
Idol_111
Member

Откуда:
Сообщений: 633
Оставим в покое этот запрос. С ним все и так ясно. Я его использовал, только для того чтобы попытаться разобраться, что же все таки произошло после апгрейда.

Меня больше волнует общее падение производетельности, что в моем случае легко идентифицируется появлением новых deadlocks.
Кто-либо сталкивался (или слышал) с ухудшением производительности после наката SP1 на SQL2008R2 или это только мне так несказанно повезло?
26 сен 11, 03:23    [11334501]     Ответить | Цитировать Сообщить модератору
 Re: Ухудшение производительности после апгрейда 2008R2  [new]
Idol_111
Member

Откуда:
Сообщений: 633
Idol_111
aleks2
DBCC USEROPTIONS

сравните.

Сервера идентичны. По крайней мере апгрейд сервера эти установки не понял.

Описка, в конце - "не поменял"
26 сен 11, 05:13    [11334513]     Ответить | Цитировать Сообщить модератору
 Re: Ухудшение производительности после апгрейда 2008R2  [new]
iljy
Member

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

могу только повторить - не надо писать такие запросы. Сервер в данном случае абсолютно не виноват, ибо с подобными чудовищами он ничего сознательно сделать не может, и получается русская рулетка. Могли чуть поменяться весовые коэффиценты оптимизатора, порядок оценки эвристик, посчет статистик и т.п., и вышла хрень. Учитесь писать.
26 сен 11, 09:47    [11334811]     Ответить | Цитировать Сообщить модератору
 Re: Ухудшение производительности после апгрейда 2008R2  [new]
Glory
Member

Откуда:
Сообщений: 104751
Idol_111
Кто-либо сталкивался (или слышал) с ухудшением производительности после наката SP1 на SQL2008R2 или это только мне так несказанно повезло?

Люди вон вообще ничего не ставят и у них производительность падает
И они тоже удивляются. Смотрят, а там просто число данных возросло и план выполнения, на который никто не глядел, показал свою сущность
Кстати у вас в плане для SQL2005 наблюдается Parallelism
Если его убрать, то что будет ?
26 сен 11, 09:53    [11334832]     Ответить | Цитировать Сообщить модератору
 Re: Ухудшение производительности после апгрейда 2008R2  [new]
ци иденитифици
Guest
Idol_111
Меня больше волнует общее падение производетельности, что в моем случае легко идентифицируется появлением новых deadlocks.

дедлоки были реализованы вашими программистами до апгрейда. с удлинением транзакций дедлоков действительно становится больше, но это не та взаимосвязь которая позволяет говорить "ухудшение производительности идентифицируется появлением дедлоков".

автор
Кто-либо сталкивался (или слышал) с ухудшением производительности после наката SP1 на SQL2008R2 или это только мне так несказанно повезло?

вы особенный. шутка. как вам уже написали, вылезли результаты творчества, а не волшебное содержимое сервиспака. вот тот шандец с вычислением дат говорит о многом. если такую херь в продакшн пускаете, значит и всё остальное не лучше (в плане производительности и дедлоков).
26 сен 11, 10:04    [11334886]     Ответить | Цитировать Сообщить модератору
 Re: Ухудшение производительности после апгрейда 2008R2  [new]
Idol_111
Member

Откуда:
Сообщений: 633
всем спасибо за ответы.

Хотя некоторые ваши высказывания не уживаются с логикой.

Когда сервер апгрейдил, данные не менялись ВООБЩЕ. Статистика считается на регулярной основе. Отсюда элементарный вывод, если ничего не менялось, кроме самого сервера, значит он и виноват. Возможно, поменялись весовые коэффициенты оптимизатора или т.п. Однако, мне от этого не легче, это же не один запрос выпал в осадок и вот теперь я должен тратить кучу времени на отлавливание причин падения производительности. От обновлений всегда ожидаешь чего-то лучшего :).

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

Glory,
Как я и писал обращать внимание на параллелизм не стоит, просто конкретно этот план снял со своей машины, на остальных установлена работа в один поток. Суть плана остается такая же.

ци иденитифици,
Когда транзакции включают в себя до сотни стейтментов, и транзакций много, и все они пересакаются так или иначе, то появление нового типа дедлога с завидной регулярностью однозначно говорит об ухудшении производительности.
27 сен 11, 05:19    [11338973]     Ответить | Цитировать Сообщить модератору
 Re: Ухудшение производительности после апгрейда 2008R2  [new]
iljy
Member

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

вчитайтесь уже наконец внимательно и вникните: при написаниие настолько корявых запросов план получается неустойчивым и зависит от чего угодно, вплоть до количества мух в устье Замбези. Соответственно, изменение коэффицентов оптимизатора, направленное на улучшение производительности в подавляющем большинстве случаев, в этом вашем конкретном может приводить к ухудшению. И неча на сервер пенять коль руки кривы.
27 сен 11, 07:58    [11339032]     Ответить | Цитировать Сообщить модератору
 Re: Ухудшение производительности после апгрейда 2008R2  [new]
ци иденитифици
Guest
автор
как вам уже написали, вылезли результаты творчества, а не волшебное содержимое сервиспака. вот тот шандец с вычислением дат говорит о многом. если такую херь в продакшн пускаете, значит и всё остальное не лучше (в плане производительности и дедлоков).

Idol_111
ци иденитифици,
Когда транзакции включают в себя до сотни стейтментов, и транзакций много, и все они пересакаются так или иначе, то появление нового типа дедлога с завидной регулярностью однозначно говорит об ухудшении производительности.

отвлеченный пример.
можно написать такой клиентский код, который выдает Access Violation иногда.
а при попытке запуска той же программы, например, на более быстром компьютере, валится каждые 0.5 секунды и не дает вобще работать. здесь уместно говорить о переезде обратно на медленный компьютер или о том что говнокод переписать не помешает?
27 сен 11, 10:28    [11339610]     Ответить | Цитировать Сообщить модератору
 Re: Ухудшение производительности после апгрейда 2008R2  [new]
Верблюд
Member

Откуда: Яженичеловек!!!
Сообщений: 65007
Idol_111
И ситуацию, когда новый сервер, ухудшая работу всей системы, помогает выявлять недочеты разработчиков, не считаю нормальной.


Правильно. Поэтому прежде чем ставить новую версию в продакшен правильные пацаны тестируют все, включая расширенное нагрузочное тестирование с эмитацией рабочей среды.
27 сен 11, 16:00    [11342905]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить