Текущее время: Пт, мар 29 2024, 00:35

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 10 ] 
Автор Сообщение
 Заголовок сообщения: Bex, проблемы производительности
СообщениеДобавлено: Вт, июл 14 2015, 17:55 
Младший специалист
Младший специалист

Зарегистрирован:
Пн, июн 25 2007, 22:27
Сообщения: 95
Пол: Мужской
Всем привет.
BW 7.4 на Windows+MSSQL. Конкретно хромает производительность, особенно на сводных отчетах по нескольким кубам.
Вопросы:
1. Анализ производительности на серваке показывает, что каждый запрос использует ровно одно ядро, при полном простое остальных. Диалоговый процесс всегда работает только на одном ядре? Не существует какой-нибудь базисной/бивишной настройки, чтобы они использовал не одно, а все свободные ядра?

2. Не совсем понятно, что он там столько времени считает.
Ниже статистика на примере одного запроса. В отчете около 30 показателей по нескольким кубам.
Ид. события___Текст события___________Продолжит.___Счетчик_____Счетчик события
9000__________Диспетчер данных________93,51________0___________24
3110__________OLAP: выбор данных______0,43________0____________1
3200__________OLAP: перенос данных____0,14________2 286________1
9010__________Сумма DBTRANS___________0,00________18 197_______1
9011__________Сумма DBSEL_____________0,00________2 514 660____1

Шаг 9000 выполняется больше полутора минут. Шаг 9000 - это именно считывание данных из БД или это их дальнейшая обработка/агрегация/расчеты? Из шага 9011 видно, что считывается около 2.5 млн записей. Как-то долго для такого количества. Сократить это количество я вряд ли смогу, все агрегаты и так уже собраны.

Любые советы, где искать затык в производительности, приветствуются.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Bex, проблемы производительности
СообщениеДобавлено: Ср, июл 15 2015, 09:49 
Гуру-эксперт
Гуру-эксперт
Аватара пользователя

Зарегистрирован:
Вс, янв 11 2009, 14:41
Сообщения: 902
Откуда: Москва
Пол: Мужской
Тр. SAT и ST05 в первую очередь,
а также нота 1681396 - Query Performance


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: Bex, проблемы производительности
СообщениеДобавлено: Пн, авг 10 2015, 18:58 
Младший специалист
Младший специалист

Зарегистрирован:
Пн, июн 25 2007, 22:27
Сообщения: 95
Пол: Мужской
После массы экспериментов, выкидывания лишних данных и т.д. - пришел к довольно простому и совершенно парадоксальному примеру.
Выглядит так, что наличие агрегата в кубе не увеличивает, а уменьшает скорость выполнения, причем в десятки раз. Я такого вообще никогда не видел до сих пор.
Похоже, что какие-то траблы с индексами, но я даже не понимаю, в какую сторону копать, т.к. все таблицы и индексы присутствуют.
Конкретный пример такой:
есть куб остатков (без некумулятивов, данные хранятся на каждую дату), называется ZST_C01.
есть на нем агрегат, называется 100089.
В F-таблице куба около 82 млн записей, в F-таблице агрегата - около 34.
Один и тот же отчет без агрегата выполняется 3-4 секунды, с агрегатом - больше минуты! Причем это все в rsrt без использования кэша.

Ниже два sql-запроса, они вообще одинаковые и отличаются на одну строку "AND F.SID_0CALMONTH = DT.SID_0CALMONTH". Я проверил - дело не в этой строке, т.е. если в запрос по агрегату добавить эту строку, то он так же тормозит.


Запрос из куба без агрегатов - выполняется 3 секунды:

Code:
select DT.SID_0CALDAY AS S____166,
       D2.SID_0PLANT AS S____352,
       DU.SID_0LOC_CURRCY AS S____454,
       DU.SID_0BASE_UOM AS S____485,
       COUNT(*) AS Z____199_SUM,
       SUM( F.[/BIC/ZSTVALN]) AS Z____489_SUM,
       SUM( F.[/BIC/ZTOTSTQTY]) AS Z____490_SUM
  FROM [/BIC/FZST_C01] F
  JOIN [/BIC/DZST_C01T] DT
    ON F.KEY_ZST_C01T = DT.DIMID
   AND F.SID_0CALMONTH = DT.SID_0CALMONTH
  JOIN [/BIC/DZST_C012] D2
    ON F.KEY_ZST_C012 = D2.DIMID
  JOIN [/BIC/DZST_C01U] DU
    ON F.KEY_ZST_C01U = DU.DIMID
  JOIN [/BIC/DZST_C01P] DP
    ON F.KEY_ZST_C01P = DP.DIMID
  JOIN [/BIC/DZST_C011] D1
    ON F.KEY_ZST_C011 = D1.DIMID
where (((( DT.SID_0CALDAY = 20150731)) AND
       ((DT.SID_0CALMONTH = 201507 AND F.SID_0CALMONTH = 201507))
        AND ((DP.SID_0CHNGID = 0)) AND
       ((D1.SID_0MATL_GROUP IN (8, 9, 11))) AND
       ((DP.SID_0REQUID <= 70676))))
GROUP BY DT.SID_0CALDAY,
         D2.SID_0PLANT,
         DU.SID_0LOC_CURRCY,
         DU.SID_0BASE_UOM
ORDER BY S____352 OPTION(MAXDOP 2)


Запрос из агрегата - выполняется больше минуты!

Code:
select DT.SID_0CALDAY  AS  S____166 ,
       D2.SID_0PLANT  AS  S____352 ,
       DU.SID_0LOC_CURRCY  AS  S____454 ,
       DU.SID_0BASE_UOM  AS  S____485 ,
       COUNT(*) AS  Z____199_SUM ,
       SUM( F.[/BIC/ZSTVALN]) AS  Z____489_SUM ,
       SUM( F.[/BIC/ZTOTSTQTY]) AS  Z____490_SUM
  FROM [/BIC/F100089]  F
  JOIN [/BIC/DZST_C01T]   DT
    ON  F.KEY_ZST_C01T  =  DT.DIMID
  JOIN [/BIC/DZST_C012]   D2
    ON  F.KEY_ZST_C012  =  D2.DIMID
  JOIN [/BIC/DZST_C01U]   DU
    ON  F.KEY_ZST_C01U  =  DU.DIMID
  JOIN [/BIC/D100089P]   DP
    ON  F.KEY_100089P  =  DP.DIMID
  JOIN [/BIC/D1000891]   D1
    ON  F.KEY_1000891  =  D1.DIMID
where (((( DT.SID_0CALDAY  = 20150731)) AND
       (( DT.SID_0CALMONTH  = 201507 AND  F.SID_0CALMONTH
         = 201507)) AND (( DP.SID_0CHNGID  = 0)) AND
       (( D1.SID_0MATL_GROUP  IN (8, 9, 11))) AND
       (( DP.SID_0REQUID  <= 70676))))
GROUP BY  DT.SID_0CALDAY ,
           D2.SID_0PLANT ,
           DU.SID_0LOC_CURRCY ,
           DU.SID_0BASE_UOM
ORDER BY  S____352  OPTION(MAXDOP 2)



Какие вообще есть варианты в такой ситуации? Что проверять?


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Bex, проблемы производительности
СообщениеДобавлено: Пн, авг 10 2015, 23:57 
Гуру-эксперт
Гуру-эксперт
Аватара пользователя

Зарегистрирован:
Вс, янв 11 2009, 14:41
Сообщения: 902
Откуда: Москва
Пол: Мужской
Вы бы лучше планы выполнения запросов выложили, которые в ST05 получите - один для куба, а другой для агрегата. Надо смотреть именно планы, где стоимость операций и порядок соединения, а не просто SQL-текст. В ST05 можно и актуальность статистики проверить - там прямо даты показаны, когда она последний раз обновлялась (по крайней мере для Oracle это справедливо)


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: Bex, проблемы производительности
СообщениеДобавлено: Вт, авг 11 2015, 12:41 
Младший специалист
Младший специалист

Зарегистрирован:
Пн, июн 25 2007, 22:27
Сообщения: 95
Пол: Мужской
Да, насчет планов - это резонно. Я их смотрел, не в ST05, а в выполнении запросов в DB02, они были абсолютно одинаковые, только разные F-таблицы подставлялись. В ST05 то же самое.
На самом деле, проблема решилась просто переактивацией и перезаполнением агрегатов.
И вот планы выполнения запроса до и после этой переактивации реально разные.

Если интересно:
До: http://my.jetscreenshot.com/demo/20150811-alnc-122kb
После: http://my.jetscreenshot.com/demo/201508 ... -253kb.jpg

Причем я специально проверил - индексы видны как созданные и активные, что через сап, что в консоли управления MSSQL. После переактивации никаких отличий в них я не нашел ни там ни там. Мистика какая-то.
Что с ними было и при каких условиях они в следующий раз перестанут работать (внешне изображая, что они есть) - непонятно.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Bex, проблемы производительности
СообщениеДобавлено: Вт, авг 11 2015, 14:18 
Гуру-эксперт
Гуру-эксперт
Аватара пользователя

Зарегистрирован:
Вс, янв 11 2009, 14:41
Сообщения: 902
Откуда: Москва
Пол: Мужской
Надо было еще и статистику смотреть, возможно ее просто требовалось обновить. Да и создавать агрегат при соотношении записей в кубе и агрегате - 82 к 34 затея, сама по себе, сомнительная. Еще такая вот любопытная нота есть 1951490 - SQL Server Column-Store for SAP BW Aggregates


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: Bex, проблемы производительности
СообщениеДобавлено: Вт, авг 11 2015, 15:28 
Младший специалист
Младший специалист

Зарегистрирован:
Пн, июн 25 2007, 22:27
Сообщения: 95
Пол: Мужской
Смотрел я статистику, она была собрана месяц назад. Это куб исторических данных, туда данные в этот момент и заливались. Я ее принудительно обновил, но ничего не поменялось.
Да и вообще все эти танцы со статистикой - это борьба за проценты, максимум за десятки процентов. Но если производительность в 30 раз ниже, чем должна быть, то статистика тут не причем, тут что-то гораздо более глобальное. Имхо, разумеется.
А про размер агрегата - да, это так, но это лучше чем ничего. Для того, чтобы собрать компактные агрегаты, нужно чтобы пользователи были готовы смотреть данные в разных местах и по четко определенным разверткам. А это далеко не всегда возможно. Плюс это не единственный агрегат, а самый большой, есть и другие более узкие.
За ноту спасибо, почитаю.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Bex, проблемы производительности
СообщениеДобавлено: Вт, авг 11 2015, 15:50 
Гуру-эксперт
Гуру-эксперт
Аватара пользователя

Зарегистрирован:
Вс, янв 11 2009, 14:41
Сообщения: 902
Откуда: Москва
Пол: Мужской
Статистика - это не борьба за проценты. От статистики напрямую зависит план выполнения запросов. На ваших скриншотах планы абсолютно разные. Такое как раз бывает от статистики. Совсем недавно сталкивался с ситуацией, когда запрос надолго подвисал. Еще были случаи, когда статистика была актуальна на F и Е-таблицах, но неактуальна на индексах или измерениях, и сервер БД строил неправильный план выполнения.


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: Bex, проблемы производительности
СообщениеДобавлено: Вт, авг 11 2015, 16:12 
Младший специалист
Младший специалист

Зарегистрирован:
Пн, июн 25 2007, 22:27
Сообщения: 95
Пол: Мужской
Хорошо, а про какую статистику речь и в какие моменты ее надо заполнять?
Насколько я понимаю, есть несколько ее типов:
1 - это то, что видно в администрировании куба, там где индексы. Она же заполняется процессом в цепочке. Это статистика по таблицам, индексам и т.д.
2 - это контентовские потоки и кубы, которые фиксируют запуск отчетов, время их выполнения и т.д.
Речь про первый вариант?
Если да, то эта статистика должна собираться после загрузки данных? Т.е. если в куб один раз залили исторические данные, собирали эту статистику и больше данные туда не грузятся, то потом ее нужно как-то периодически обновлять?


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Bex, проблемы производительности
СообщениеДобавлено: Вт, авг 11 2015, 17:31 
Гуру-эксперт
Гуру-эксперт
Аватара пользователя

Зарегистрирован:
Вс, янв 11 2009, 14:41
Сообщения: 902
Откуда: Москва
Пол: Мужской
Да, речь про первый вариант. Если данные в куб не загружались, то статистика измениться не должна была (если ее, конечно, не вычистили преднамеренно на уровне БД). Но статистика могла потерять свою актуальность, например, если на кубе был агрегат, в него был включен навигационный атрибут, то тогда при прогоне изменения атрибутов признака будет происходить изменение агрегата и статистика таблиц агрегата, в принципе, должна меняться, то есть может стать неактуальной, хотя данные в куб не загружались


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 10 ] 

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Русская поддержка phpBB