Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3 4 5   вперед  Ctrl      все
 Эпическая деградация производительности  [new]
aborigen
Member

Откуда:
Сообщений: 51
Всем привет.

Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

С субботы у нас запросы пользователей (интерактивно и из джобов) стали отрабатывать раз в 10-20 дольше обычного.
С тех пор и до текущего момента пользовательская нагрузка - совсем как обычно (в V$SESSION ничего криминального).

На сервере видим, что CPU используется на все 100)

Вместе с DBA уже голову сломали.

Как найти причину проблемы?
14 дек 16, 23:48    [20004962]     Ответить | Цитировать Сообщить модератору
 Re: Эпическая деградация производительности  [new]
Relic Hunter
Member

Откуда: AB
Сообщений: 7433
aborigen,

И что? По AWR-ам уже ничего нельзя предположить? :)
15 дек 16, 00:17    [20005051]     Ответить | Цитировать Сообщить модератору
 Re: Эпическая деградация производительности  [new]
xtender
Member

Откуда: Мск
Сообщений: 5704
aborigen,

хотя бы awr diff приложили бы...
15 дек 16, 00:55    [20005107]     Ответить | Цитировать Сообщить модератору
 Re: Эпическая деградация производительности  [new]
Taciturn12
Member

Откуда:
Сообщений: 74
Что именно генерирует такую высокую нагрузку на процессор, если нагрузка идет от базы, тогда определяйте какие сессии ее вызывают, потом разбираться с конкретными сессиями проще. Если используется Linux то с определением сессий проблем не будет, если Windows то для определения сессий можно использовать ProcessExplorer, в нем можно посмотреть загрузку процессора каждым из потоков процесса Oracle.
15 дек 16, 06:22    [20005203]     Ответить | Цитировать Сообщить модератору
 Re: Эпическая деградация производительности  [new]
aborigen
Member

Откуда:
Сообщений: 51
Relic Hunter,

в прошлые инкарнации проблемы (тогда условно согласились на проблемы с дисками) по AWR-у куча ожиданий было в топе.
Сейчас аналогичные проблемы с дисками проверили - вроде всё в порядке.
15 дек 16, 07:54    [20005249]     Ответить | Цитировать Сообщить модератору
 Re: Эпическая деградация производительности  [new]
aborigen
Member

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

попробуем.
15 дек 16, 07:55    [20005250]     Ответить | Цитировать Сообщить модератору
 Re: Эпическая деградация производительности  [new]
aborigen
Member

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

это уже интереснее.

Вложил top и htop.
Там куча процессов жрёт немерянно CPU.
А на деле активно штук 10-20 обычных пользовательских запросов.
Неделю назад база на нагрузку раза в 3 больше не особо реагировала.

К сообщению приложен файл. Размер - 146Kb
15 дек 16, 08:11    [20005264]     Ответить | Цитировать Сообщить модератору
 Re: Эпическая деградация производительности  [new]
Taciturn12
Member

Откуда:
Сообщений: 74
Ну теперь по найденным PID смотрите какие это сессии, что делают, чего ждут, на каких запросах висят, возможно простой перезапуск этих сессий решит проблему, но конечно сначала лучше разобраться с чего они стали так грузить систему. Возможно таким способом найти причину будет проще чем ковырять AWR.
15 дек 16, 08:17    [20005272]     Ответить | Цитировать Сообщить модератору
 Re: Эпическая деградация производительности  [new]
Elic
Member

Откуда:
Сообщений: 29990
aborigen
Там куча процессов жрёт немерянно CPU.
Кто-то включил параллелизм?
15 дек 16, 08:24    [20005281]     Ответить | Цитировать Сообщить модератору
 Re: Эпическая деградация производительности  [new]
опс...
Guest
если "Вместе с DBA уже голову сломали", то пока это выглядит как детский сад какой-то.
15 дек 16, 08:25    [20005284]     Ответить | Цитировать Сообщить модератору
 Re: Эпическая деградация производительности  [new]
Taciturn12
Member

Откуда:
Сообщений: 74
Опишу ситуацию у нас с загрузкой процессора.
В приложении был старый не используемый функционал, в процессе доработки приложения за время пока этот функционал не использовался пакеты в базе наменяли так, что при попытке выполнить этот функционал, код зацикливался. В определенный момент приложение было установлено новой группе пользователей, которые по незнанию стали тыкать в этот функционал. Система являлась вспомогательной и небольшой (всего на 100 пользователей), поэтому работала на слабеньком сервере с 2 процессорами по 4 ядра в каждом. Как результат пользователи начали жаловаться на скорость работы и сразу выяснилось, что у 6 пользователей был запущен этот зациклившийся функционал, что съело 6 из 8 доступных ядер. На все остальное приходилось всего 2 ядра, что вызвало дикую конкуренцию за процессор и соответственно сильное замедление.
15 дек 16, 08:26    [20005286]     Ответить | Цитировать Сообщить модератору
 Re: Эпическая деградация производительности  [new]
опс...
Guest
Taciturn12
Опишу ситуацию у нас с загрузкой процессора... что вызвало дикую конкуренцию за процессор и соответственно сильное замедление.

эта чрезвычайно занимательная история конечно очень поможет в гаданиях ТС ))
щаз еще с десяток байды всякой понавспоминают

полнолуние, однако
15 дек 16, 08:34    [20005300]     Ответить | Цитировать Сообщить модератору
 Re: Эпическая деградация производительности  [new]
Игорь Ковалев
Member

Откуда:
Сообщений: 57
Можете AWR-отчёт выложить?
15 дек 16, 09:14    [20005369]     Ответить | Цитировать Сообщить модератору
 Re: Эпическая деградация производительности  [new]
Игорь Ковалев
Member

Откуда:
Сообщений: 57
Сталкивался с ситуацией, когда часть ядер процессора в Oracle перегружена, остальные
наоборот загружены мало. Причина была в тяжелых запросах sql, нагружающих процессор.
Если одновременно таких запросов было мало, проблем с производительностью не наблюдалось.
Как понимаю под соединение с Oracle от пользователя отводится некое ядро процессора, если соединений больше, чем ядер на отдельные ядра нагрузка может быть больше и Oracle эту нагрузку между ядрами не балансирует. Кроме того ядра бывают не полностью независимые, а например по 2 через гипертрейдинг, которые тоже между собой за ресурсы конкурируют.
15 дек 16, 09:26    [20005408]     Ответить | Цитировать Сообщить модератору
 Re: Эпическая деградация производительности  [new]
Koresh
Member

Откуда: Когда где..
Сообщений: 414
aborigen,
в моей практике, когда я занимался разработкой на Oracle, очень похожие симптомы были при заполнении TEMP TABLESPACE.

Если так, то в качестве быстрого решения можно пробовать в разы увеличить TEMP, и параллельно разбираться с неэффективными запросами.
15 дек 16, 10:09    [20005590]     Ответить | Цитировать Сообщить модератору
 Re: Эпическая деградация производительности  [new]
aabezugly
Member

Откуда:
Сообщений: 5
И ещё одна попытка выложить AWR

К сообщению приложен файл (AWR Rpt - EDW Snap 18101 thru 18102.rar - 45Kb) cкачать
15 дек 16, 10:47    [20005833]     Ответить | Цитировать Сообщить модератору
 Re: Эпическая деградация производительности  [new]
Nobody1111
Guest
Koresh
aborigen,
в моей практике, когда я занимался разработкой на Oracle, очень похожие симптомы были при заполнении TEMP TABLESPACE.

Если так, то в качестве быстрого решения можно пробовать в разы увеличить TEMP, и параллельно разбираться с неэффективными запросами.


Что-то не в тему. Заполнение TEMP может дать ошибки Unable to extend..... Замедление может дать чересчур активное использование TEMP, но с заполнением это в общем случае не взаимообусловлено.
15 дек 16, 10:48    [20005838]     Ответить | Цитировать Сообщить модератору
 Re: Эпическая деградация производительности  [new]
Nobody1111
Guest
Правда, если в системе выставлен RESUMABLE_TIMEOUT, то сессии до того, как получить ошибку переполнения, будут просто зависать на этот таймаут
15 дек 16, 10:59    [20005941]     Ответить | Цитировать Сообщить модератору
 Re: Эпическая деградация производительности  [new]
Игорь Ковалев
Member

Откуда:
Сообщений: 57
Запрос с sql_id d99wbughxy7yb
больше всего ресурсов процессора потребляет и
за час не выполнился.
Может можно от него избавиться или заменить на другой?
15 дек 16, 11:06    [20005990]     Ответить | Цитировать Сообщить модератору
 Re: Эпическая деградация производительности  [new]
Melkomyagkii_newbi
Member

Откуда: из прошлого
Сообщений: 1863
У меня недавно было, оказалось из-за пары запросов у которых слетел план. Гляньте прям по v$session where status = 'ACTIVE' что за запросы превалируют в момент высокого cpu и проверьте не менялся ли план недавно на более худший.

До этого случая был еще один - из-за патчинга в Solarisе, но там system cpu был больше половины. pg_contig_disable=1 помог.
http://knowledgebase.progress.com/articles/Article/P147903
15 дек 16, 11:07    [20005995]     Ответить | Цитировать Сообщить модератору
 Re: Эпическая деградация производительности  [new]
aabezugly
Member

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

Спасибо за совет, но как понять какой раньше был план?
15 дек 16, 11:13    [20006039]     Ответить | Цитировать Сообщить модератору
 Re: Эпическая деградация производительности  [new]
Jebrail
Member

Откуда: Тбилиси
Сообщений: 328
aabezugly
Melkomyagkii_newbi,

Спасибо за совет, но как понять какой раньше был план?


EM -> Performance -> Search SQL -> SQL_ID из топа AWR например .


Ну и вообще на заглавной странице будут они .
15 дек 16, 11:57    [20006349]     Ответить | Цитировать Сообщить модератору
 Re: Эпическая деградация производительности  [new]
shr?
Guest
немного оффтоп,
но подскажите, пожалуйста, почему
на скрине ТОРа shr от 18m до 27m в то время как судя по awr sga=56g
15 дек 16, 12:33    [20006528]     Ответить | Цитировать Сообщить модератору
 Re: Эпическая деградация производительности  [new]
Melkomyagkii_newbi
Member

Откуда: из прошлого
Сообщений: 1863
Jebrail
aabezugly
Melkomyagkii_newbi,

Спасибо за совет, но как понять какой раньше был план?


EM -> Performance -> Search SQL -> SQL_ID из топа AWR например .


Ну и вообще на заглавной странице будут они .


Если нет EM или доступа к нему, можно и запросами посмотреть. Я использую следующие.
Это вроде истории изменений плана:
select ss.snap_id, ss.instance_number node, begin_interval_time, sql_id, plan_hash_value,
nvl(executions_delta,0) execs,
(elapsed_time_delta/decode(nvl(executions_delta,0),0,1,executions_delta))/1000000 avg_etime,
(buffer_gets_delta/decode(nvl(buffer_gets_delta,0),0,1,executions_delta)) avg_lio
from DBA_HIST_SQLSTAT S, DBA_HIST_SNAPSHOT SS
where sql_id = '3vm2703cc7a9j'
and ss.snap_id = S.snap_id
and ss.instance_number = S.instance_number
and executions_delta > 0
order by 3 desc
;
 
 


Этот поможет выбрать наилучший из существовавших планов.(правда тут нужно учитывать еще что какой-то мог устареть из-за того что данных стало больше например)
WITH
p AS (
SELECT plan_hash_value
  FROM gv$sql_plan
WHERE sql_id = TRIM('&sql_id')
   AND other_xml IS NOT NULL
UNION
SELECT plan_hash_value
  FROM dba_hist_sql_plan
WHERE sql_id = TRIM('&&sql_id')
   AND other_xml IS NOT NULL ),
m AS (
SELECT plan_hash_value, SUM(executions) execs, 
       SUM(elapsed_time)/SUM(executions) avg_et_secs
  FROM gv$sql
WHERE sql_id = TRIM('&&sql_id')
   AND executions > 0
GROUP BY
       plan_hash_value ),
a AS (
SELECT plan_hash_value, SUM(executions_total) execs,
       SUM(elapsed_time_total)/SUM(executions_total) avg_et_secs
  FROM dba_hist_sqlstat
WHERE sql_id = TRIM('&&sql_id')
   AND executions_total > 0
GROUP BY
       plan_hash_value )
SELECT p.plan_hash_value, nvl(m.execs, a.execs) execs,
       ROUND(NVL(m.avg_et_secs, a.avg_et_secs)/1e6, 3) avg_et_secs
  FROM p, m, a
WHERE p.plan_hash_value = m.plan_hash_value(+)
   AND p.plan_hash_value = a.plan_hash_value(+)
ORDER BY avg_et_secs NULLS LAST;
15 дек 16, 13:50    [20006955]     Ответить | Цитировать Сообщить модератору
 Re: Эпическая деградация производительности  [new]
Игорь Ковалев
Member

Откуда:
Сообщений: 57
Разберитесь, почему запрос с
sql_id d99wbughxy7yb

выполняется более часа и сильно потребляет процессор.

Можете сделать AWR-отчет за прошлый период времени, когда проблем с производительностью не было и посмотреть, что было с этим запросом - как он портеблял ресурсы процессора,
какое время выполнялся.
15 дек 16, 14:49    [20007448]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3 4 5   вперед  Ctrl      все
Все форумы / Oracle Ответить