ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Эпическая деградация производительности
114 сообщений из 114, показаны все 5 страниц
  все  
Эпическая деградация производительности
    #39367264
aborigen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
aborigen
Гость
Всем привет.

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

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

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

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

Как найти причину проблемы?
...
Рейтинг: 0 / 0
14.12.2016, 23:48
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39367269
Фотография Relic Hunter
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Relic Hunter
Участник
aborigen,

И что? По AWR-ам уже ничего нельзя предположить? :)
...
Рейтинг: 0 / 0
15.12.2016, 00:17
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39367280
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sayan Malakshinov
Модератор форума
aborigen,

хотя бы awr diff приложили бы...
...
Рейтинг: 0 / 0
15.12.2016, 00:55
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39367307
Taciturn12
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Taciturn12
Гость
Что именно генерирует такую высокую нагрузку на процессор, если нагрузка идет от базы, тогда определяйте какие сессии ее вызывают, потом разбираться с конкретными сессиями проще. Если используется Linux то с определением сессий проблем не будет, если Windows то для определения сессий можно использовать ProcessExplorer, в нем можно посмотреть загрузку процессора каждым из потоков процесса Oracle.
...
Рейтинг: 0 / 0
15.12.2016, 06:22
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39367317
aborigen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
aborigen
Гость
Relic Hunter,

в прошлые инкарнации проблемы (тогда условно согласились на проблемы с дисками) по AWR-у куча ожиданий было в топе.
Сейчас аналогичные проблемы с дисками проверили - вроде всё в порядке.
...
Рейтинг: 0 / 0
15.12.2016, 07:54
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39367318
aborigen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
aborigen
Гость
xtender,

попробуем.
...
Рейтинг: 0 / 0
15.12.2016, 07:55
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39367320
aborigen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
aborigen
Гость
Taciturn12,

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

Вложил top и htop.
Там куча процессов жрёт немерянно CPU.
А на деле активно штук 10-20 обычных пользовательских запросов.
Неделю назад база на нагрузку раза в 3 больше не особо реагировала.
...
Рейтинг: 0 / 0
15.12.2016, 08:11
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39367323
Taciturn12
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Taciturn12
Гость
Ну теперь по найденным PID смотрите какие это сессии, что делают, чего ждут, на каких запросах висят, возможно простой перезапуск этих сессий решит проблему, но конечно сначала лучше разобраться с чего они стали так грузить систему. Возможно таким способом найти причину будет проще чем ковырять AWR.
...
Рейтинг: 0 / 0
15.12.2016, 08:17
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39367325
Фотография Elic
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Elic
Участник
aborigenТам куча процессов жрёт немерянно CPU.Кто-то включил параллелизм?
...
Рейтинг: 0 / 0
15.12.2016, 08:24
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39367327
опс...
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
опс...
Гость
если "Вместе с DBA уже голову сломали", то пока это выглядит как детский сад какой-то.
...
Рейтинг: 0 / 0
15.12.2016, 08:25
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39367329
Taciturn12
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Taciturn12
Гость
Опишу ситуацию у нас с загрузкой процессора.
В приложении был старый не используемый функционал, в процессе доработки приложения за время пока этот функционал не использовался пакеты в базе наменяли так, что при попытке выполнить этот функционал, код зацикливался. В определенный момент приложение было установлено новой группе пользователей, которые по незнанию стали тыкать в этот функционал. Система являлась вспомогательной и небольшой (всего на 100 пользователей), поэтому работала на слабеньком сервере с 2 процессорами по 4 ядра в каждом. Как результат пользователи начали жаловаться на скорость работы и сразу выяснилось, что у 6 пользователей был запущен этот зациклившийся функционал, что съело 6 из 8 доступных ядер. На все остальное приходилось всего 2 ядра, что вызвало дикую конкуренцию за процессор и соответственно сильное замедление.
...
Рейтинг: 0 / 0
15.12.2016, 08:26
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39367333
опс...
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
опс...
Гость
Taciturn12Опишу ситуацию у нас с загрузкой процессора... что вызвало дикую конкуренцию за процессор и соответственно сильное замедление.
эта чрезвычайно занимательная история конечно очень поможет в гаданиях ТС ))
щаз еще с десяток байды всякой понавспоминают

полнолуние, однако
...
Рейтинг: 0 / 0
15.12.2016, 08:34
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39367343
Игорь Ковалев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Игорь Ковалев
Участник
Можете AWR-отчёт выложить?
...
Рейтинг: 0 / 0
15.12.2016, 09:14
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39367348
Игорь Ковалев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Игорь Ковалев
Участник
Сталкивался с ситуацией, когда часть ядер процессора в Oracle перегружена, остальные
наоборот загружены мало. Причина была в тяжелых запросах sql, нагружающих процессор.
Если одновременно таких запросов было мало, проблем с производительностью не наблюдалось.
Как понимаю под соединение с Oracle от пользователя отводится некое ядро процессора, если соединений больше, чем ядер на отдельные ядра нагрузка может быть больше и Oracle эту нагрузку между ядрами не балансирует. Кроме того ядра бывают не полностью независимые, а например по 2 через гипертрейдинг, которые тоже между собой за ресурсы конкурируют.
...
Рейтинг: 0 / 0
15.12.2016, 09:26
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39367376
Koresh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Koresh
Участник
aborigen,
в моей практике, когда я занимался разработкой на Oracle, очень похожие симптомы были при заполнении TEMP TABLESPACE.

Если так, то в качестве быстрого решения можно пробовать в разы увеличить TEMP, и параллельно разбираться с неэффективными запросами.
...
Рейтинг: 0 / 0
15.12.2016, 10:09
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39367409
aabezugly
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
aabezugly
Гость
И ещё одна попытка выложить AWR
...
Рейтинг: 0 / 0
15.12.2016, 10:47
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39367411
Nobody1111
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Nobody1111
Гость
Koreshaborigen,
в моей практике, когда я занимался разработкой на Oracle, очень похожие симптомы были при заполнении TEMP TABLESPACE.

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

Что-то не в тему. Заполнение TEMP может дать ошибки Unable to extend..... Замедление может дать чересчур активное использование TEMP, но с заполнением это в общем случае не взаимообусловлено.
...
Рейтинг: 0 / 0
15.12.2016, 10:48
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39367429
Nobody1111
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Nobody1111
Гость
Правда, если в системе выставлен RESUMABLE_TIMEOUT, то сессии до того, как получить ошибку переполнения, будут просто зависать на этот таймаут
...
Рейтинг: 0 / 0
15.12.2016, 10:59
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39367439
Игорь Ковалев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Игорь Ковалев
Участник
Запрос с sql_id d99wbughxy7yb
больше всего ресурсов процессора потребляет и
за час не выполнился.
Может можно от него избавиться или заменить на другой?
...
Рейтинг: 0 / 0
15.12.2016, 11:06
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39367440
Melkomyagkii_newbi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Melkomyagkii_newbi
Участник
У меня недавно было, оказалось из-за пары запросов у которых слетел план. Гляньте прям по v$session where status = 'ACTIVE' что за запросы превалируют в момент высокого cpu и проверьте не менялся ли план недавно на более худший.

До этого случая был еще один - из-за патчинга в Solarisе, но там system cpu был больше половины. pg_contig_disable=1 помог.
http://knowledgebase.progress.com/articles/Article/P147903
...
Рейтинг: 0 / 0
15.12.2016, 11:07
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39367448
aabezugly
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
aabezugly
Гость
Melkomyagkii_newbi,

Спасибо за совет, но как понять какой раньше был план?
...
Рейтинг: 0 / 0
15.12.2016, 11:13
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39367505
Фотография Jebrail
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Jebrail
Участник
aabezuglyMelkomyagkii_newbi,

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

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


Ну и вообще на заглавной странице будут они .
...
Рейтинг: 0 / 0
15.12.2016, 11:57
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39367553
shr?
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
shr?
Гость
немного оффтоп,
но подскажите, пожалуйста, почему
на скрине ТОРа shr от 18m до 27m в то время как судя по awr sga=56g
...
Рейтинг: 0 / 0
15.12.2016, 12:33
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39367682
Melkomyagkii_newbi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Melkomyagkii_newbi
Участник
JebrailaabezuglyMelkomyagkii_newbi,

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

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


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

Если нет EM или доступа к нему, можно и запросами посмотреть. Я использую следующие.
Это вроде истории изменений плана:
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
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
;



Этот поможет выбрать наилучший из существовавших планов.(правда тут нужно учитывать еще что какой-то мог устареть из-за того что данных стало больше например)
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
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;
...
Рейтинг: 0 / 0
15.12.2016, 13:50
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39367783
Игорь Ковалев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Игорь Ковалев
Участник
Разберитесь, почему запрос с
sql_id d99wbughxy7yb

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

Можете сделать AWR-отчет за прошлый период времени, когда проблем с производительностью не было и посмотреть, что было с этим запросом - как он портеблял ресурсы процессора,
какое время выполнялся.
...
Рейтинг: 0 / 0
15.12.2016, 14:49
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39367845
опс...
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
опс...
Гость
Игорь КовалевРазберитесь, почему запрос с
sql_id d99wbughxy7yb выполняется более часа и сильно потребляет процессор.

вот только мне так грустно на все это смотреть?
-
ТС выложил свой awr.
далее почти все считают его полным ..., неспособным найти там запрос, который больше всего потребляет cpu ? да еще он вдвоем с dba по его же словам.
как говорится - кто хуже в данной ситуации ?
...
Рейтинг: 0 / 0
15.12.2016, 15:28
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39367868
booby
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
booby
Участник
опс...вот только мне так грустно на все это смотреть?
-

Не грусти так. На заголовок топика глянь.
Здесь не о простой деградации рассказ, а об эпической.
...
Рейтинг: 0 / 0
15.12.2016, 15:41
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368033
Тролин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тролин
Участник
aborigen,

1. Как собирается статистика, по умолчанию или есть джоб? с какими параметрами?
2. Отключите на время параллелизм.
3.
попробовать:
open_cursors=1000
parallel_max_servers=0
parallel_servers_target=0
processes=1000
sessions должно автоматически увеличится или принудительно поставить 1000
...
Рейтинг: 0 / 0
15.12.2016, 17:55
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368085
aborigen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
aborigen
Гость
Тролин,

1. Самописный джоб, запускается по вторникам, инкрементально собирает статистику по ключевым схемам.

2.+3. Попробуем. Но тут с виду не в параллели дело - активных сессий мало.
...
Рейтинг: 0 / 0
15.12.2016, 19:00
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368088
aborigen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
aborigen
Гость
Elic,

Не, с давних лет включен.
...
Рейтинг: 0 / 0
15.12.2016, 19:04
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368093
landy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
landy
Участник
а в alert.log ничего нет?
...
Рейтинг: 0 / 0
15.12.2016, 19:14
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368099
Тролин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тролин
Участник
aborigen, параметры сбора статистики показать можете? и инкремент и полная?
...
Рейтинг: 0 / 0
15.12.2016, 19:18
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368105
ну_робяты
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ну_робяты
Гость
Тролинprocesses=1000
sessions должно автоматически увеличится или принудительно поставить 1000
о, еще один ))
в awr же все видно, чего гадать-то. проще пареной репы все.
...
Рейтинг: 0 / 0
15.12.2016, 19:27
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368107
ну_робяты
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ну_робяты
Гость
автор, ты сам-то смотрел свой awr ?
просто интересно, что ты сам там видишь или не видишь совсем ? давай, не бойся, скажи свою мысль )
а то действительно топик очень кхгм странно смотрится )
...
Рейтинг: 0 / 0
15.12.2016, 19:33
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368117
Тролин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тролин
Участник
ну_робяты,
я по awr по текущим параметрам посмотрел, что значения по умолчанию стоят...и их в большенстве случаях не хватает.
...
Рейтинг: 0 / 0
15.12.2016, 19:48
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368174
aborigen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
aborigen
Гость
ну_робяты,

смотрел.

Выглядит как будто база просто нагружена

Statistic Name Time (s) % of DB Time
sql execute elapsed time 27,967.88 99.35
DB CPU 27,933.61 99.23

+ самые обычные PX Deq.

В топе самые простые (объективно) запросы типа DELETE FROM PWF_UNIQ_ID.
Значит попали они туда из-за того, что на сервере перегруз по использованию CPU, а не потому что реально тяжелы.

Сравнение AWR в процессе.

В прошлую инкарнацию похожих проблем корапнулся то ли один redo, то ли archivelog, и у rman скопилась мегаочередь.
Эта очередь и давила на мозги серверу.
...
Рейтинг: 0 / 0
15.12.2016, 21:35
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368178
aborigen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
aborigen
Гость
landy,

landyа в alert.log ничего нет?

сейчас с виду нет.

Но вообще в понедельник обнаружили, что с последняя запись там от 17 ноября.
...
Рейтинг: 0 / 0
15.12.2016, 21:45
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368181
aborigen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
aborigen
Гость
Тролин,

DBMS_STATS.SET_SCHEMA_PREFS(ownname => '...', pname => 'CASCADE', pvalue => 'TRUE');

DBMS_STATS.SET_SCHEMA_PREFS(ownname => '...', pname => 'DEGREE', pvalue => '4');

DBMS_STATS.SET_SCHEMA_PREFS(ownname => '...', pname => 'ESTIMATE_PERCENT', pvalue => '100');

DBMS_STATS.SET_SCHEMA_PREFS(ownname => '...', pname => 'METHOD_OPT', pvalue => 'FOR ALL COLUMNS SIZE 1');

DBMS_STATS.GATHER_SCHEMA_STATS(ownname => '...', options => 'GATHER AUTO');

Вот это по ключевым схемам по вторникам, более ничего.
...
Рейтинг: 0 / 0
15.12.2016, 21:50
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368191
landy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
landy
Участник
а как там с redo?

Код: plsql
1.
select * from v$log;



???
...
Рейтинг: 0 / 0
15.12.2016, 22:01
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368203
aabezugly
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
aabezugly
Гость
landy,

top - 23:36:08 up 1 day, 5:12, 2 users, load average: 10.87, 10.36, 9.94
Tasks: 945 total, 11 running, 934 sleeping, 0 stopped, 0 zombie

1 [|||||100.0%] 5 [|| 2.0%] 9 [|| 1.5%] 13 [|||||100.0%]
2 [||| 18.5%] 6 [| 0.5%] 10 [||||||72.4%] 14 [|||||100.0%]
3 [|| 2.0%] 7 [| 3.0%] 11 [|||||100.0%] 15 [|||||100.0%]
4 [||| 25.3%] 8 [|| 1.5%] 12 [| 1.5%] 16 [|||||100.0%]
Mem[|||||||||||||||||65029/96696MB] Tasks: 177, 99 thr; 8 running
Swp[| 250/99999MB] Load average: 7.18 7.30 7.71
Uptime: 1 day, 05:39:13

PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command
36550 oracle 20 0 60.3G 82376 23552 R 101. 0.1 3h55:00 ora_p011_EDW
32086 oracle 20 0 60.3G 42560 23820 R 101. 0.0 3h24:27 ora_p002_EDW
36548 oracle 20 0 60.3G 70736 18632 R 101. 0.1 3h55:06 ora_p010_EDW
36073 oracle 20 0 60.2G 27320 22692 R 101. 0.0 2h19:39 oracleEDW (LOCAL=
32082 oracle 20 0 60.3G 35848 23536 R 101. 0.0 3h14:53 ora_p000_EDW
32084 oracle 20 0 60.3G 38516 25796 R 100. 0.0 3h14:46 ora_p001_EDW
39563 oracle 20 0 60.2G 30140 25244 S 60.6 0.0 3:24.27 oracleEDW (LOCAL=
40905 root 20 0 110M 2180 1232 R 28.2 0.0 8:07.99 htop
5685 oracle -2 0 1306M 2292 2176 S 11.0 0.0 2h35:23 asm_vktm_+ASM
5561 oracle 20 0 1637M 21332 8336 S 8.4 0.0 2h24:36 /opt/oracle/produ
30064 oracle 20 0 60.3G 55524 40112 R 7.8 0.1 57:08.78 oracleEDW (LOCAL=
27619 oracle -2 0 60.2G 15808 13784 S 7.3 0.0 58:53.19 ora_vktm_EDW
5693 oracle 20 0 1309M 16324 13868 S 3.7 0.0 40:25.92 asm_dia0_+ASM

[oracle@bigoak ~]$ rlwrap sqlplus / as sysdba


sys@edw>;select * from v$log;

GROUP# THREAD# SEQUENCE# BYTES BLOCKSIZE MEMBERS ARC STATUS
FIRST_CHANGE# FIRST_TIM NEXT_CHANGE# NEXT_TIME
---------- ---------- ---------- ---------- ---------- ---------- --- ----------
------ ------------- --------- ------------ ---------
8 1 26747 5368709120 512 1 NO CURRENT
2082440292 15-DEC-16 2.8147E+14
9 1 26746 5368709120 512 1 YES INACTIVE
2082440233 15-DEC-16 2082440292 15-DEC-16
10 1 26743 5368709120 512 1 YES INACTIVE
2082404302 15-DEC-16 2082425146 15-DEC-16
11 1 26744 5368709120 512 1 YES INACTIVE
2082425146 15-DEC-16 2082425249 15-DEC-16
12 1 26745 5368709120 512 1 YES INACTIVE
2082425249 15-DEC-16 2082440233 15-DEC-16
13 1 26742 5368709120 512 1 YES INACTIVE
2082404251 15-DEC-16 2082404302 15-DEC-16

6 rows selected.

sys@edw>;/

GROUP# THREAD# SEQUENCE# BYTES BLOCKSIZE MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIM NEXT_CHANGE# NEXT_TIME
---------- ---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- --------- ------------ ---------
8 1 26747 5368709120 512 1 NO CURRENT 2082440292 15-DEC-16 2.8147E+14
9 1 26746 5368709120 512 1 YES INACTIVE 2082440233 15-DEC-16 2082440292 15-DEC-16
10 1 26743 5368709120 512 1 YES INACTIVE 2082404302 15-DEC-16 2082425146 15-DEC-16
11 1 26744 5368709120 512 1 YES INACTIVE 2082425146 15-DEC-16 2082425249 15-DEC-16
12 1 26745 5368709120 512 1 YES INACTIVE 2082425249 15-DEC-16 2082440233 15-DEC-16
13 1 26742 5368709120 512 1 YES INACTIVE 2082404251 15-DEC-16 2082404302 15-DEC-16

6 rows selected.
...
Рейтинг: 0 / 0
15.12.2016, 22:57
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368206
aabezugly
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
aabezugly
Гость
И вот (во вложении) AWR diff.

Количество запросов при этом от пользователей во второй момент времени меньше. Из-за низкой производительности.
...
Рейтинг: 0 / 0
15.12.2016, 23:01
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368257
Фотография SeaGate
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SeaGate
Участник
aabezugly,

Кроме того, что уже сказали, следующие запросы от modelerserver.exe

4fk0u72qzy7aj DELETE FROM PWF_UNIQ_ID (вызывается из: 29zhgfkwdhzmg modelerserver.exe begin uniq_id_update(); end; )
78f96ptngbtwq DELETE FROM "PWF_NOT_AVAILABLE"

Здесь рассмотрите возможность использования TRUNCATE или различные альтернативные решения, позволяющие реализовать out-of-place refresh, если нужна доступность данных: exchange partition, create or replace view, create or replace synonym, dbms_redefinition.

В целом, судя по всяким alipatyev, alena, в топах, похоже на песочницу, в которой копаются юзеры, удовлетворяя конечных пользователей/автоматику, ждущих отчетов.
Нужно лимитировать и резать их по ресурсам, чтобы не мешали друг другу.
DBRM -ом
...
Рейтинг: 0 / 0
16.12.2016, 05:23
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368266
aborigen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
aborigen
Гость
SeaGate,

даже интересно, почему ни здесь, ни в других местах, никто не верит, что это всё - не просто возросшая пользовательская нагрузка) Тут всё работает медленнее, чем раньше, даже когда в базе пара человек с конкретными приличными запросами.
...
Рейтинг: 0 / 0
16.12.2016, 07:10
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368268
aborigen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
aborigen
Гость
aborigen,

а ещё гугль говорит, что подскочившие VM_IN_BYTES и VM_OUT_BYTES могут говорить о том,
что сервер swap-ит.

Логически это может что-то объяснить с нагрузкой на CPU.

Но вот схрена ли он свопит..
...
Рейтинг: 0 / 0
16.12.2016, 07:23
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368274
aabezugly
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
aabezugly
Гость
SeaGate,

Да, aborigen прав, проблема в том, что уже третий раз за два года работы сервера у нас происходят подобные случае. Запросы пользователей не меняются, но в один не очень прекрасный момент происходит что-то из-за чего все запросы начинают дико тормозить.
Буквально все выборки проседают от 5 до 15 раз. Insert'ы работают в два/три раза хуже обычного.

И как найти причину этого вот в чем главная задача.

По основным тяжелым запросам мы сразу дали рекомендации пользователям, но даже после замены delete на truncate лучше то стало только этому процессу, остальные запросы других пользователей к абсолютно всем таблицам базы работают в разы хуже чем раньше...
...
Рейтинг: 0 / 0
16.12.2016, 08:00
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368280
landy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
landy
Участник
а что показывают
iostat -xm 5
sar 1

???
...
Рейтинг: 0 / 0
16.12.2016, 08:13
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368283
Игорь Ковалев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Игорь Ковалев
Участник
Попробуйте посмотреть через ASH, что происходило с замедлившимися запросами - какие
там события ожидания и сравнить с аналогичной ситуацией когда с производительностью проблем не было.
...
Рейтинг: 0 / 0
16.12.2016, 08:24
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368297
Фотография Alexey Zhidkov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Zhidkov
Участник
Тролинprocesses=1000
коим обком это относится к данной теме и из каких соображений взято данное значение? :)
...
Рейтинг: 0 / 0
16.12.2016, 09:18
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368298
Фотография Alexey Zhidkov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Zhidkov
Участник
*боком
...
Рейтинг: 0 / 0
16.12.2016, 09:19
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368309
ORA__SQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ORA__SQL
Участник
Что за детский сад.
Покажите план запроса для
Код: plsql
1.
select a.rn , A.EVENT_DT , A.TEXT_LINE from alipatyev.V_MON_ALERT a where 1=1 and A.EVENT_DT>=trunc(sysdate)-1 order by a.rn


1. Что внутри вьюхи(?) V_MON_ALERT
2. Есть ли индекс по A.EVENT_DT и какова селективность предиката A.EVENT_DT>=trunc(sysdate)-1
...
Рейтинг: 0 / 0
16.12.2016, 09:33
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368316
aborigen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
aborigen
Гость
ORA__SQL,
...
Рейтинг: 0 / 0
16.12.2016, 09:46
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368321
aborigen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
aborigen
Гость
ORA__SQL,

1. Что внутри вьюхи(?) V_MON_ALERT
2. Есть ли индекс по A.EVENT_DT и какова селективность предиката A.EVENT_DT>=trunc(sysdate)-1

1. Аналитические функции поверх выгрузки ALERT.LOG в обычную таблицу.
2. EVENT_DT считается этой самой аналитикой, индексировать нечего.

тему не читай@отвечай?

Я глубоко благодарен за разные идеи по оптимизации конкретных запросов,
но ещё раз: баянов типа замены delete на truncate и индексирования у нас самих в достатке.
...
Рейтинг: 0 / 0
16.12.2016, 09:52
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368330
ORA__SQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ORA__SQL
Участник
aborigen1. Аналитические функции поверх выгрузки ALERT.LOG в обычную таблицу.
2. EVENT_DT считается этой самой аналитикой, индексировать нечего.Что вы пытаетесь вычислить аналитикой? Поделитесь текстом вьюхи. Или хотя бы алгоритмом расчета A.EVENT_DT
...
Рейтинг: 0 / 0
16.12.2016, 10:03
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368332
тынц.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
тынц.
Гость
то, что видно - у запросов, чисто кушающих cpu как-то действительно маловато число gets за час ~13млн всего. конечно от железа зависит и других нюансов.
соответственно - либо в pl/sql логике затык(если что-то прицеплено мощное в триггерах), либо проблема в ос или железе.
...
Рейтинг: 0 / 0
16.12.2016, 10:05
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368343
ORA__SQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ORA__SQL
Участник
тынц.то, что видно - у запросов, чисто кушающих cpu как-то действительно маловато число gets за час ~13млн всего. конечно от железа зависит и других нюансов.
соответственно - либо в pl/sql логике затык(если что-то прицеплено мощное в триггерах), либо проблема в ос или железе.Сортировки?
...
Рейтинг: 0 / 0
16.12.2016, 10:16
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368348
тынц.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
тынц.
Гость
ORA__SQLСортировки?
при delete ? ))))
...
Рейтинг: 0 / 0
16.12.2016, 10:18
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368362
ORA__SQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ORA__SQL
Участник
тынц.ORA__SQLСортировки?
при delete ? ))))В топе по cpu - select, но и при delete в общем случае никто не мешает сортировать
...
Рейтинг: 0 / 0
16.12.2016, 10:32
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368373
тынц.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
тынц.
Гость
aborigenа ещё гугль говорит, что подскочившие VM_IN_BYTES и VM_OUT_BYTES могут говорить о том,
что сервер swap-ит.Логически это может что-то объяснить с нагрузкой на CPU.
Но вот схрена ли он свопит..
ничего он у вас не свопит: vm_out_bytes =0
и пространства там мизер использовано судя по скрину.
...
Рейтинг: 0 / 0
16.12.2016, 10:42
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368375
aborigen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
aborigen
Гость
ORA__SQL,

содержимое ALERT.LOG Вы себе представляете.
Даты там не в каждой строке, а я хочу отфильтровать свежие данные.
Поэтому вываливаю из external table на базе ALERT.LOG данные в обычную heap-organized.
Далее LEAD-ом распространяю дату на строки до следующей даты.

Предвосхищая предложения про стандартную external table на базе alert.xml из sys-а:
если у нас пофетчить побольше строк, то вылезают разные ошибки типа поле слишком длинное.
...
Рейтинг: 0 / 0
16.12.2016, 10:46
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368380
aborigen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
aborigen
Гость
тынц.,

в diff-е видно, что сейчас VM_ <>0.
...
Рейтинг: 0 / 0
16.12.2016, 10:47
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368384
landy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
landy
Участник
Покажете

iostat -xm 5
sar 1

???
...
Рейтинг: 0 / 0
16.12.2016, 10:48
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368397
123йй
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
123йй
Участник
aborigenсодержимое ALERT.LOG Вы себе представляете.
дикари
...
Рейтинг: 0 / 0
16.12.2016, 10:58
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368406
ORA__SQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ORA__SQL
Участник
aborigenORA__SQL,
содержимое ALERT.LOG Вы себе представляете.
Даты там не в каждой строке, а я хочу отфильтровать свежие данные.
Поэтому вываливаю из external table на базе ALERT.LOG данные в обычную heap-organized.
Далее LEAD-ом распространяю дату на строки до следующей даты.
Если очень хочется залить в таблицу, то
1. Забудьте про аналитику
1. Измените алгоритм загрузки (дата должна быть определена до insert)
2. Сделайте partitition by date для таблицы приемника
...
Рейтинг: 0 / 0
16.12.2016, 11:05
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368411
aborigen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
aborigen
Гость
123йй,

ну что сказать, по существу.

Много буков.
Вы уверены, что этот инструмент поможет мне получить содержимое ALERT.LOG через SQL-интерфейс?
...
Рейтинг: 0 / 0
16.12.2016, 11:07
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368412
aborigen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
aborigen
Гость
ORA__SQL,

давайте остановимся на том, что скорость работы этого функционала всех устраивает.
...
Рейтинг: 0 / 0
16.12.2016, 11:09
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368415
trace.log
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
trace.log
Гость
А что говорит ОЕМ насчет скриптов работающих в БД? Может он оптимальное решение предложит?
...
Рейтинг: 0 / 0
16.12.2016, 11:13
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368416
ORA__SQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ORA__SQL
Участник
aborigenORA__SQL,
давайте остановимся на том, что скорость работы этого функционала всех устраивает.Цель оптимизации не просто ускорить функционал, а высвободить ресурсы, которые вы схавали одним запросом )
...
Рейтинг: 0 / 0
16.12.2016, 11:15
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368419
Тролин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тролин
Участник
Alexey Zhidkov, ниже мои сообщения прочитай.
...
Рейтинг: 0 / 0
16.12.2016, 11:19
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368420
aborigen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
aborigen
Гость
ORA__SQL,

запрос этот запускался уже несколько месяцев ежедневно и работал минут по 40.
А сейчас общая производительность просела и кажется, что запрос всё сожрал.
А на деле связь скорее обратная.
...
Рейтинг: 0 / 0
16.12.2016, 11:22
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368421
aborigen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
aborigen
Гость
landy,

сисадмины в процессе.
...
Рейтинг: 0 / 0
16.12.2016, 11:22
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368425
Koresh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Koresh
Участник
aborigen,

я уже писал выше, взгляните все же на temp.

Я четко помню ситуацию, когда было так, что при забитом temp мелкие запросы отрабатывали, но в разы медленнее,
а "гиганты" которые и забивали temp, висели часами и только затем выдавалось "unable to extent"..
...
Рейтинг: 0 / 0
16.12.2016, 11:29
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368436
тынц.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
тынц.
Гость
KoreshЯ четко помню ситуацию, когда было так
друг, ты конечно наверно хороший, но уйди пожалуйста )
тебя все уже услышали
...
Рейтинг: 0 / 0
16.12.2016, 11:37
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368551
тынц.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
тынц.
Гость
ну и еще раз, уже отмечали - глядя на предоставленный вами снимок top, видно что у вас основную часть процессоров выжирают параллельные -т.е. вполне возможно, что один запрос из-за параллельности фактически убивает все остальное, забрав под себя сразу пачку процессоров.
...
Рейтинг: 0 / 0
16.12.2016, 12:59
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368559
тынц.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
тынц.
Гость
и соответственно возвращаясь снова тогда на то же самое - разберитесь со своим топовым запросом.
...
Рейтинг: 0 / 0
16.12.2016, 13:04
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368612
Игорь Ковалев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Игорь Ковалев
Участник
aborigenORA__SQL,

запрос этот запускался уже несколько месяцев ежедневно и работал минут по 40.
А сейчас общая производительность просела и кажется, что запрос всё сожрал.
А на деле связь скорее обратная.
Посмотрите на решение по анализу alert.log по ссылке, возможно побыстрее будет
и ресурсы процессора поэкономнее будет расходовать.
https://asktom.oracle.com/pls/asktom/f?p=100:11:3800578428791239::::P11_QUESTION_ID:1352202934074
...
Рейтинг: 0 / 0
16.12.2016, 13:39
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368657
ora601
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ora601
Участник
Ставлю на параллельные процессы от чего то системного (DML/DDL parallelized =0 AWR). Уже можно было давно было посмотреть что делают эти PID и отрубить их или закенселить выволнение.
...
Рейтинг: 0 / 0
16.12.2016, 14:18
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368672
parallel_qry
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
parallel_qry
Гость
ora601Ставлю на параллельные процессы от чего то системного (DML/DDL parallelized =0 AWR). Уже можно было давно было посмотреть что делают эти PID и отрубить их или закенселить выволнение.
упустили queries parallelized 4
...
Рейтинг: 0 / 0
16.12.2016, 14:26
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368842
aborigen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
aborigen
Гость
Игорь Ковалев,

спасибо.

Мне нужны все строки, а не только с ORA.
А тут row-by-row.
Хотя, конечно, может и выиграть у текущего подхода.

В целом, этот подход перекликается с идеями ORA__SQL.
...
Рейтинг: 0 / 0
16.12.2016, 16:52
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368863
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sayan Malakshinov
Модератор форума
aborigen,
aabezugly,

выполните awr extract
Код: plsql
1.
@?/rdbms/admin/awrextr

в sqlplus и выложите (или пришлите мне на почту в профиле)
и еще дайте дамп v$active_session_history: создайте таблицу через ctas from ash и экспортните ее
Код: plsql
1.
create table ... as select * from v$active_session_history;
...
Рейтинг: 0 / 0
16.12.2016, 17:12
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368866
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sayan Malakshinov
Модератор форума
вообще мне не нравится db_block_size... С не стандартными часто какая-нибудь фигня всплывает
...
Рейтинг: 0 / 0
16.12.2016, 17:16
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368869
ORA__SQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ORA__SQL
Участник
xtenderвообще мне не нравится db_block_size... С не стандартными часто какая-нибудь фигня всплываетА чем тебе 16К блок не угодил? Вроде 4К, 8К и 16К стандартными считались всегда
...
Рейтинг: 0 / 0
16.12.2016, 17:20
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368882
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sayan Malakshinov
Модератор форума
опс...Игорь КовалевРазберитесь, почему запрос с
sql_id d99wbughxy7yb выполняется более часа и сильно потребляет процессор.

вот только мне так грустно на все это смотреть?
-
ТС выложил свой awr.
далее почти все считают его полным ..., неспособным найти там запрос, который больше всего потребляет cpu ? да еще он вдвоем с dba по его же словам.
как говорится - кто хуже в данной ситуации ?так запрос выполняется минимум в 3 сессиях(а скорее всего в 4, просто 4-я запущена была позднее) и сжирает 38% CPU, то есть минимум 3 ядра полностью сжирает.

aborigen,
aabezugly,
выложите
Код: plsql
1.
2.
3.
select * 
from v$active_session_history h
where h.sql_id='d99wbughxy7yb'
...
Рейтинг: 0 / 0
16.12.2016, 17:34
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368894
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sayan Malakshinov
Модератор форума
ORA__SQL,

я стандартным называю 8k, с остальными часто всякая фигня:
https://savvinov.com/2014/11/17/followup-on-the-4k-dml-bug/
https://jonathanlewis.wordpress.com/2009/03/22/block-size-again/
https://jonathanlewis.wordpress.com/2008/07/19/block-sizes/
...
...
Рейтинг: 0 / 0
16.12.2016, 17:46
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368899
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sayan Malakshinov
Модератор форума
xtenderORA__SQL,

я стандартным называю 8k, с остальными часто всякая фигня:
https://savvinov.com/2014/11/17/followup-on-the-4k-dml-bug/
https://jonathanlewis.wordpress.com/2009/03/22/block-size-again/
https://jonathanlewis.wordpress.com/2008/07/19/block-sizes/
...еще:
http://oracle-randolf.blogspot.ae/2011/05/assm-bug-reprise-part-1.html
http://oracle-randolf.blogspot.ae/2011/05/assm-bug-reprise-part-2.html
...
Рейтинг: 0 / 0
16.12.2016, 17:50
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368908
ORA__SQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ORA__SQL
Участник
xtenderxtenderORA__SQL,

я стандартным называю 8k, с остальными часто всякая фигня:
https://savvinov.com/2014/11/17/followup-on-the-4k-dml-bug/
https://jonathanlewis.wordpress.com/2009/03/22/block-size-again/
https://jonathanlewis.wordpress.com/2008/07/19/block-sizes/
...еще:
http://oracle-randolf.blogspot.ae/2011/05/assm-bug-reprise-part-1.html
http://oracle-randolf.blogspot.ae/2011/05/assm-bug-reprise-part-2.html
Спасибо. Полезное чтиво.
Но в 99% случаев пеформанс страдает из-за неудачной архитектуры. И рассматриваемый случай - не исключение.
До таких тонкостой еще далеко
...
Рейтинг: 0 / 0
16.12.2016, 17:59
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368910
Фотография SeaGate
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SeaGate
Участник
xtender,

xtenderи еще дайте дамп v$active_session_history: создайте таблицу через ctas from ash и экспортните ее
Я бы ashdumpseconds+tracefile, меньше возни лично для меня, когда удаленные изучения ASH случаются.
Лодырем потом запузырить в песочницу, там в трассе все для этого есть.
...
Рейтинг: 0 / 0
16.12.2016, 18:00
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368914
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sayan Malakshinov
Модератор форума
ORA__SQLНо в 99% случаев пеформанс страдает из-за неудачной архитектуры.вот именно, поэтому менять db_block_size как правило и не надо, пока более полезные вещи не сделаны, а с учетом того, что с другими размерами в оракле не тестируют, то нафига искать приключений?
...
Рейтинг: 0 / 0
16.12.2016, 18:04
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368915
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sayan Malakshinov
Модератор форума
SeaGate,

да это то абсолютно то же самое - в обоих случаях просто экспортируется табличка
...
Рейтинг: 0 / 0
16.12.2016, 18:05
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368923
Фотография SeaGate
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SeaGate
Участник
xtender,

off: DDL не выполняется, объект в базе не создается, редо не генерится, база потом спасибо скажет :)

Чем там на x86 щас утилизацию core смотрите, кстати? Вчера на SPARC-ах pgstat-ом ковырялся, на Linux пока не было таких задач.
...
Рейтинг: 0 / 0
16.12.2016, 18:11
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368925
ORA__SQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ORA__SQL
Участник
SeaGatextender,
off: DDL не выполняется, объект в базе не создается, редо не генерится, база потом спасибо скажет :)3 копейки сэкономили
...
Рейтинг: 0 / 0
16.12.2016, 18:14
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368942
тынц.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
тынц.
Гость
aborigenИгорь Ковалев,
спасибо.
Мне нужны все строки, а не только с ORA.
А тут row-by-row.
вот как раз по ссылке, которую он вам кинул, в самом низу- в последнем посте - есть имя системной таблицы, которая в 11g уже за вас смаплена на alert. выбирайте из нее все что душе угодно.
...
Рейтинг: 0 / 0
16.12.2016, 18:22
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368948
тынц.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
тынц.
Гость
aborigen
а чего про процессы параллельности, которые в топе os у вас почти все и съели ничего не говорите ?
разобрались с ними ?
...
Рейтинг: 0 / 0
16.12.2016, 18:25
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368949
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sayan Malakshinov
Модератор форума
тынц.,

К слову работает она с предикатами крайне хреново. Я обходил это материализацией всего и только потом накладывал предикаты
...
Рейтинг: 0 / 0
16.12.2016, 18:26
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368951
Фотография SeaGate
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SeaGate
Участник
тынц.,

небоянист1. Аналитические функции поверх выгрузки ALERT.LOG в обычную таблицу.
2. EVENT_DT считается этой самой аналитикой, индексировать нечего.
По теме проблемного запроса и этой задачи, я бы на их месте alert.log в syslog направил и потом консолидировал бы это через rsyslog со всех БД нужных в хозяйстве, лил бы в БД какую угодно, но чтобы к анализу alert.log-а критичные к производительности системы были не причастны.
Иначе опять какой-нить alipatyev или ALENA, захочет очередной запрос написать и разогреют одно-сокетную шушлайку.
...
Рейтинг: 0 / 0
16.12.2016, 18:26
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368955
тынц.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
тынц.
Гость
xtenderтынц.,
К слову работает она с предикатами крайне хреново. Я обходил это материализацией всего и только потом накладывал предикаты
ну если как-то сложно, может быть и так. у нас например за последний день заданный, если требуется - просматривает за пару сек
...
Рейтинг: 0 / 0
16.12.2016, 18:32
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368971
Фотография SeaGate
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SeaGate
Участник
Было пару лет назад, на новый непрогретый edition переключались, онлайн обновление (EBR), latch: row cache objects (на dc_users) прервал утренний кофе, розовое latch free, на каком уже не помню, но следствие первого.
В топике не так эпично.
...
Рейтинг: 0 / 0
16.12.2016, 19:15
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368973
Фотография SeaGate
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SeaGate
Участник
2006 год, pa-risc-и (cas latch), тогда латчи больше угрожали галактике.
...
Рейтинг: 0 / 0
16.12.2016, 19:16
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368987
aborigen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
aborigen
Гость
тынц.,

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

про это я писал:

Предвосхищая предложения про стандартную external table на базе alert.xml из sys-а:
если у нас пофетчить побольше строк, то вылезают разные ошибки типа поле слишком длинное.

Не взлетело.
Времени разбираться не было.
...
Рейтинг: 0 / 0
16.12.2016, 20:12
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368991
aborigen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
aborigen
Гость
тынц.,

а чего про процессы параллельности, которые в топе os у вас почти все и съели ничего не говорите ?
разобрались с ними ?

Рабочая версия до сих пор - проблемы не в прикладном коде, работающем с базой.
Даже сразу после рестарта базы и сервера производительность запросов низкая.

Пока вырубили dg4odbc, стало раза в 2 получше, но всё равно в несколько раз хуже, чем обычно.
...
Рейтинг: 0 / 0
16.12.2016, 20:17
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368994
Melkomyagkii_newbi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Melkomyagkii_newbi
Участник
aborigenтынц.,

а чего про процессы параллельности, которые в топе os у вас почти все и съели ничего не говорите ?
разобрались с ними ?

Рабочая версия до сих пор - проблемы не в прикладном коде, работающем с базой.
Даже сразу после рестарта базы и сервера производительность запросов низкая.

Пока вырубили dg4odbc, стало раза в 2 получше, но всё равно в несколько раз хуже, чем обычно.

А рестарт базы фиксит прикладной код? Какие ожидания у запросов которые работают медленнее? Планы ни у кого не менялись?
...
Рейтинг: 0 / 0
16.12.2016, 20:23
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39368999
aborigen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
aborigen
Гость
Melkomyagkii_newbi,

написал недостаточно детально.

Даже после гашения всех сессий кроме пары собственных с проверенными запросами производительность не возвращается в норму.
...
Рейтинг: 0 / 0
16.12.2016, 20:31
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39369000
тынц.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
тынц.
Гость
aborigenа чего про процессы параллельности, которые в топе os у вас почти все и съели ничего не говорите ?
разобрались с ними ?
Рабочая версия до сих пор - проблемы не в прикладном коде, работающем с базой.
ну вы тогда каким-то гаданием занимаетесь, либо что-то утаиваете от общественности ))
вы же сами выложили скрин, на котором четко видно, кто жрет ваши cpu.
про параллельность же вы старательно почему-то обходите стороной.

т.е. показываете одни данные, которые однозначно показывают на источник проблем.
но при этом говорите, что все не так как всем видется. тень на плетень.
на что опираться - на какого-то таинственного барабашку ?.
проблемы не в прикладном коде говорите - так сделайте тест, погоняйте какие-нибудь программы, грузящие cpu или память, посмотрите.
смысл тогда выкладывать было скрины, awr - но типа это все не то.
что анализировать тогда - слова, что все почему-то плохо работает ?
...
Рейтинг: 0 / 0
16.12.2016, 20:37
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39369002
тынц.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
тынц.
Гость
aborigenMelkomyagkii_newbi,
написал недостаточно детально.
Даже после гашения всех сессий кроме пары собственных с проверенными запросами производительность не возвращается в норму.
нужно делать сопоставимый анализ - те же запросы, с примерно тем же кол-вом лог.чтений.
когда нормально и когда плохо. awr-ки две, а не dif, в котором заколебешься ковыряться. и снимок top процессов при этом.
нарисуйте просто прогу какую-нибудь на чем можете, засеките ее производительность.

или у вас сейчас просто всегда теперь - медленно безвозвратно ?
...
Рейтинг: 0 / 0
16.12.2016, 20:43
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39369003
тынц.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
тынц.
Гость
железо свое конкретно укажите - может у кого похожее есть сравнить
...
Рейтинг: 0 / 0
16.12.2016, 20:46
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39369004
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sayan Malakshinov
Модератор форума
aborigenMelkomyagkii_newbi,

написал недостаточно детально.

Даже после гашения всех сессий кроме пары собственных с проверенными запросами производительность не возвращается в норму.А это типа детально? вы нарочно ничего не показываете из запрошенного?
...
Рейтинг: 0 / 0
16.12.2016, 20:49
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39369024
Melkomyagkii_newbi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Melkomyagkii_newbi
Участник
xtenderaborigenMelkomyagkii_newbi,

написал недостаточно детально.

Даже после гашения всех сессий кроме пары собственных с проверенными запросами производительность не возвращается в норму.А это типа детально? вы нарочно ничего не показываете из запрошенного?

Ну хоть что-то) Раз пара проверенных запросов висит - значит не в cpu корень зла был(скорее всего)..

И что ваши проверенные запросы ждут? ASH в студию, как xtender просил для того запроса, только для ваших проверенных(и тот который xtender просил тоже).
План не поменялся? Его, пожалуйста, тоже в студию.
...
Рейтинг: 0 / 0
16.12.2016, 22:03
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39369038
дык
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
дык
Гость
Melkomyagkii_newbiНу хоть что-то) Раз пара проверенных запросов висит - значит не в cpu корень зла был(скорее всего)..

но по выложенному AWR почти вся нагрузка - cpu, ничего другого серьезного там не видно
...
Рейтинг: 0 / 0
16.12.2016, 22:33
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39369064
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sayan Malakshinov
Модератор форума
SeaGatextender,

off: DDL не выполняется, объект в базе не создается, редо не генерится, база потом спасибо скажет :)
обычно к ASH еще кучу прочего нужно, так что все равно экспортировать придется еще что-нибудь

SeaGateЧем там на x86 щас утилизацию core смотрите, кстати? Вчера на SPARC-ах pgstat-ом ковырялся, на Linux пока не было таких задач.ps, top, htop
...
Рейтинг: 0 / 0
16.12.2016, 23:25
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39369298
Фотография SeaGate
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SeaGate
Участник
xtenderps, top, htop
Эти инструменты известны, утилизацию core я через них не смогу посмотреть, только thread/logical processors utilization.
Их можно использовать для не SMT, для SMT я с помощью этих инструментов не смогу сказать, насколько core утилизированы, в общем случае.
В Solaris для этого есть pgstat .
В AIX тоже допилили стандартные утилиты: Understanding CPU utilization on AIX
...
Рейтинг: 0 / 0
17.12.2016, 17:08
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39369303
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sayan Malakshinov
Модератор форума
SeaGate,

top + 1?
...
Рейтинг: 0 / 0
17.12.2016, 17:17
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39369391
landy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
landy
Участник
Так мы увидим все-таки

sar 1
iostat -xm 5

или админы пешком пошли запускать?
...
Рейтинг: 0 / 0
17.12.2016, 20:44
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39369753
Фотография SeaGate
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SeaGate
Участник
xtender,

xtendertop + 1?
Нет, это thread-ы, не physical core.
Например, вот мой десктоп:
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
$ lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                8
On-line CPU(s) list:   0-7
Thread(s) per core:    2
Core(s) per socket:    4
Socket(s):             1
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 42
Model name:            Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
Stepping:              7
CPU MHz:               1732.995
CPU max MHz:           3800.0000
CPU min MHz:           1600.0000
BogoMIPS:              6784.27
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              8192K
NUMA node0 CPU(s):     0-7
Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm epb tpr_shadow vnmi flexpriority ept vpid xsaveopt dtherm ida arat pln pts


Вот top + 1, выдающий 8 logical cpu:
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
top - 07:38:56 up 19 days, 23:39, 32 users,  load average: 0,85, 0,79, 0,79
Tasks: 495 total,   2 running, 493 sleeping,   0 stopped,   0 zombie
%Cpu0  :  0,7 us,  0,7 sy,  0,0 ni, 97,3 id,  1,0 wa,  0,0 hi,  0,3 si,  0,0 st
%Cpu1  :  1,7 us,  0,7 sy,  0,0 ni, 97,4 id,  0,0 wa,  0,0 hi,  0,3 si,  0,0 st
%Cpu2  :  0,7 us,  0,3 sy,  0,0 ni, 99,0 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
%Cpu3  :  1,0 us,  0,3 sy,  0,0 ni, 98,0 id,  0,0 wa,  0,3 hi,  0,3 si,  0,0 st
%Cpu4  : 71,1 us,  0,7 sy,  0,0 ni, 27,9 id,  0,0 wa,  0,3 hi,  0,0 si,  0,0 st
%Cpu5  :  0,3 us,  0,0 sy,  0,0 ni, 99,7 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
%Cpu6  :  0,0 us,  0,3 sy,  0,0 ni, 99,7 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
%Cpu7  :  3,0 us,  0,0 sy,  0,0 ni, 97,0 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
KiB Mem : 16300548 total,   693812 free,  7537388 used,  8069348 buff/cache
KiB Swap:  3817468 total,  2446996 free,  1370472 used.  5499032 avail Mem
...
Рейтинг: 0 / 0
19.12.2016, 03:45
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39369790
landy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
landy
Участник
У вас в свопе 1 гиг - что там?
На диски можно все-таки взглянуть?
На производительность не только загрузка цпу влияет ...
...
Рейтинг: 0 / 0
19.12.2016, 08:02
| Ответить | Цитировать | Написать  
Эпическая деградация производительности
    #39370047
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sayan Malakshinov
Модератор форума
SeaGate,

так а зачем? так же детальнее - какой vcpu на каком ядре же понятно? ну и irix mode выключать надо конечно
...
Рейтинг: 0 / 0
19.12.2016, 13:01
| Ответить | Цитировать | Написать  
114 сообщений из 114, показаны все 5 страниц
  все  
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Эпическая деградация производительности
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?all=1&fid=52&tid=1886788]:
 0ms
get settings:
 10ms
get forum list:
 15ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 52ms
get topic data:
 10ms
get forum data:
 3ms
get page messages:
 141ms
get tp. blocked users:
 2ms
others: 251ms
total:  492ms
созд. / загр.: 492ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]