Эпическая деградация производительности / Oracle

ReSQL.ru

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Новые сообщения | Избранное

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

Введите код, изображенный на картинке. Если код нечитаемый, кликните картинку, чтобы загрузить другой вариант.

Отправляя сообщение, я выражаю свое согласие с правилами форума и принимаю пользовательское соглашение.

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / Oracle [игнор отключен] [закрыт для гостей] / Эпическая деградация производительности

25 сообщений из 114, страница 2 из 5

все

Эпическая деградация производительности

#39367845

опс...

Гость

Игорь КовалевРазберитесь, почему запрос с
sql_id d99wbughxy7yb выполняется более часа и сильно потребляет процессор.

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

...

Рейтинг:

0 / 0

15.12.2016, 15:28

| Ответить | Цитировать | Написать

Эпическая деградация производительности

#39367868

booby

Участник

Сообщения: 2 667

Рейтинг: 1 / 0

опс...вот только мне так грустно на все это смотреть?
-

Не грусти так. На заголовок топика глянь.
Здесь не о простой деградации рассказ, а об эпической.

...

Рейтинг:

0 / 0

15.12.2016, 15:41

| Ответить | Цитировать | Написать

Эпическая деградация производительности

#39368033

Тролин

Участник

Откуда: БСП

Сообщения: 513

Рейтинг: 0 / 0

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

Гость

Тролин,

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

2.+3. Попробуем. Но тут с виду не в параллели дело - активных сессий мало.

...

Рейтинг:

0 / 0

15.12.2016, 19:00

| Ответить | Цитировать | Написать

Эпическая деградация производительности

#39368088

aborigen

Гость

Elic,

Не, с давних лет включен.

...

Рейтинг:

0 / 0

15.12.2016, 19:04

| Ответить | Цитировать | Написать

Эпическая деградация производительности

#39368093

landy

Участник

Сообщения: 1 531

Рейтинг: 0 / 0

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

...

Рейтинг:

0 / 0

15.12.2016, 19:14

| Ответить | Цитировать | Написать

Эпическая деградация производительности

#39368099

Тролин

Участник

Откуда: БСП

Сообщения: 513

Рейтинг: 0 / 0

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

Тролин

Участник

Откуда: БСП

Сообщения: 513

Рейтинг: 0 / 0

ну_робяты,
я по awr по текущим параметрам посмотрел, что значения по умолчанию стоят...и их в большенстве случаях не хватает.

...

Рейтинг:

0 / 0

15.12.2016, 19:48

| Ответить | Цитировать | Написать

Эпическая деградация производительности

#39368174

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

Гость

landy,

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

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

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

...

Рейтинг:

0 / 0

15.12.2016, 21:45

| Ответить | Цитировать | Написать

Эпическая деградация производительности

#39368181

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

Участник

Сообщения: 1 531

Рейтинг: 0 / 0

а как там с redo?

Код: plsql

select * from v$log;

???

...

Рейтинг:

0 / 0

15.12.2016, 22:01

| Ответить | Цитировать | Написать

Эпическая деградация производительности

#39368203

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

Гость

И вот (во вложении) AWR diff.

Количество запросов при этом от пользователей во второй момент времени меньше. Из-за низкой производительности.

...

Рейтинг:

0 / 0

15.12.2016, 23:01

| Ответить | Цитировать | Написать

Эпическая деградация производительности

#39368257

SeaGate

Участник

Откуда: Новосибирск

Сообщения: 1 759

Рейтинг: 6 / 0

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

Гость

SeaGate,

даже интересно, почему ни здесь, ни в других местах, никто не верит, что это всё - не просто возросшая пользовательская нагрузка) Тут всё работает медленнее, чем раньше, даже когда в базе пара человек с конкретными приличными запросами.

...

Рейтинг:

0 / 0

16.12.2016, 07:10

| Ответить | Цитировать | Написать

Эпическая деградация производительности

#39368268

aborigen

Гость

aborigen,

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

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

Но вот схрена ли он свопит..

...

Рейтинг:

0 / 0

16.12.2016, 07:23

| Ответить | Цитировать | Написать

Эпическая деградация производительности

#39368274

aabezugly

Гость

SeaGate,

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

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

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

...

Рейтинг:

0 / 0

16.12.2016, 08:00

| Ответить | Цитировать | Написать

Эпическая деградация производительности

#39368280

landy

Участник

Сообщения: 1 531

Рейтинг: 0 / 0

а что показывают
iostat -xm 5
sar 1

???

...

Рейтинг:

0 / 0

16.12.2016, 08:13

| Ответить | Цитировать | Написать

Эпическая деградация производительности

#39368283

Игорь Ковалев

Участник

Сообщения: 58

Рейтинг: 0 / 0

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

...

Рейтинг:

0 / 0

16.12.2016, 08:24

| Ответить | Цитировать | Написать

Эпическая деградация производительности

#39368297

Alexey Zhidkov

Участник

Откуда: Москва

Сообщения: 1 075

Рейтинг: 0 / 0

Тролинprocesses=1000
коим обком это относится к данной теме и из каких соображений взято данное значение? :)

...

Рейтинг:

0 / 0

16.12.2016, 09:18

| Ответить | Цитировать | Написать

Эпическая деградация производительности

#39368298

Alexey Zhidkov

Участник

Откуда: Москва

Сообщения: 1 075

Рейтинг: 0 / 0

*боком

...

Рейтинг:

0 / 0

16.12.2016, 09:19

| Ответить | Цитировать | Написать

Эпическая деградация производительности

#39368309

ORA__SQL

Участник

Откуда: Moscow

Сообщения: 1 767

Рейтинг: 0 / 0

Что за детский сад.
Покажите план запроса для

Код: plsql

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

| Ответить | Цитировать | Написать

25 сообщений из 114, страница 2 из 5

все

Форумы / Oracle [игнор отключен] [закрыт для гостей] / Эпическая деградация производительности

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?fid=52&msg=39368117&tid=1886788]:	0ms
get settings:	11ms
get forum list:	12ms
check forum access:	4ms
check topic access:	4ms
track hit:	171ms
get topic data:	11ms
get forum data:	3ms
get page messages:	67ms
get tp. blocked users:	2ms
others:	245ms

total:	530ms

	Необходимые cookie
	Cookie для сбора статистики
	Cookie для маркетинга и рекламы