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


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