ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Эпическая деградация производительности
25 сообщений из 114, страница 3 из 5
  3  все
Эпическая деградация производительности
    #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
| Ответить | Цитировать | Написать  
25 сообщений из 114, страница 3 из 5
  3  все
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Эпическая деградация производительности
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=52&msg=39368419&tid=1886788]:
 0ms
get settings:
 10ms
get forum list:
 17ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 185ms
get topic data:
 12ms
get forum data:
 3ms
get page messages:
 87ms
get tp. blocked users:
 2ms
others: 256ms
total:  580ms
созд. / загр.: 580ms
x
x
Закрыть


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