|
|
|
Эпическая деградация производительности
|
|||
|---|---|---|---|
|
#18+
Всем привет. Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production С субботы у нас запросы пользователей (интерактивно и из джобов) стали отрабатывать раз в 10-20 дольше обычного. С тех пор и до текущего момента пользовательская нагрузка - совсем как обычно (в V$SESSION ничего криминального). На сервере видим, что CPU используется на все 100) Вместе с DBA уже голову сломали. Как найти причину проблемы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2016, 23:48 |
|
||
|
Эпическая деградация производительности
|
|||
|---|---|---|---|
|
#18+
aborigen, И что? По AWR-ам уже ничего нельзя предположить? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2016, 00:17 |
|
||
|
Эпическая деградация производительности
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2016, 00:55 |
|
||
|
Эпическая деградация производительности
|
|||
|---|---|---|---|
|
#18+
Что именно генерирует такую высокую нагрузку на процессор, если нагрузка идет от базы, тогда определяйте какие сессии ее вызывают, потом разбираться с конкретными сессиями проще. Если используется Linux то с определением сессий проблем не будет, если Windows то для определения сессий можно использовать ProcessExplorer, в нем можно посмотреть загрузку процессора каждым из потоков процесса Oracle. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2016, 06:22 |
|
||
|
Эпическая деградация производительности
|
|||
|---|---|---|---|
|
#18+
Relic Hunter, в прошлые инкарнации проблемы (тогда условно согласились на проблемы с дисками) по AWR-у куча ожиданий было в топе. Сейчас аналогичные проблемы с дисками проверили - вроде всё в порядке. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2016, 07:54 |
|
||
|
Эпическая деградация производительности
|
|||
|---|---|---|---|
|
#18+
xtender, попробуем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2016, 07:55 |
|
||
|
Эпическая деградация производительности
|
|||
|---|---|---|---|
|
#18+
Taciturn12, это уже интереснее. Вложил top и htop. Там куча процессов жрёт немерянно CPU. А на деле активно штук 10-20 обычных пользовательских запросов. Неделю назад база на нагрузку раза в 3 больше не особо реагировала. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2016, 08:11 |
|
||
|
Эпическая деградация производительности
|
|||
|---|---|---|---|
|
#18+
Ну теперь по найденным PID смотрите какие это сессии, что делают, чего ждут, на каких запросах висят, возможно простой перезапуск этих сессий решит проблему, но конечно сначала лучше разобраться с чего они стали так грузить систему. Возможно таким способом найти причину будет проще чем ковырять AWR. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2016, 08:17 |
|
||
|
Эпическая деградация производительности
|
|||
|---|---|---|---|
|
#18+
aborigenТам куча процессов жрёт немерянно CPU.Кто-то включил параллелизм? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2016, 08:24 |
|
||
|
Эпическая деградация производительности
|
|||
|---|---|---|---|
|
#18+
если "Вместе с DBA уже голову сломали", то пока это выглядит как детский сад какой-то. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2016, 08:25 |
|
||
|
Эпическая деградация производительности
|
|||
|---|---|---|---|
|
#18+
Опишу ситуацию у нас с загрузкой процессора. В приложении был старый не используемый функционал, в процессе доработки приложения за время пока этот функционал не использовался пакеты в базе наменяли так, что при попытке выполнить этот функционал, код зацикливался. В определенный момент приложение было установлено новой группе пользователей, которые по незнанию стали тыкать в этот функционал. Система являлась вспомогательной и небольшой (всего на 100 пользователей), поэтому работала на слабеньком сервере с 2 процессорами по 4 ядра в каждом. Как результат пользователи начали жаловаться на скорость работы и сразу выяснилось, что у 6 пользователей был запущен этот зациклившийся функционал, что съело 6 из 8 доступных ядер. На все остальное приходилось всего 2 ядра, что вызвало дикую конкуренцию за процессор и соответственно сильное замедление. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2016, 08:26 |
|
||
|
Эпическая деградация производительности
|
|||
|---|---|---|---|
|
#18+
Taciturn12Опишу ситуацию у нас с загрузкой процессора... что вызвало дикую конкуренцию за процессор и соответственно сильное замедление. эта чрезвычайно занимательная история конечно очень поможет в гаданиях ТС )) щаз еще с десяток байды всякой понавспоминают полнолуние, однако ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2016, 08:34 |
|
||
|
Эпическая деградация производительности
|
|||
|---|---|---|---|
|
#18+
Можете AWR-отчёт выложить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2016, 09:14 |
|
||
|
Эпическая деградация производительности
|
|||
|---|---|---|---|
|
#18+
Сталкивался с ситуацией, когда часть ядер процессора в Oracle перегружена, остальные наоборот загружены мало. Причина была в тяжелых запросах sql, нагружающих процессор. Если одновременно таких запросов было мало, проблем с производительностью не наблюдалось. Как понимаю под соединение с Oracle от пользователя отводится некое ядро процессора, если соединений больше, чем ядер на отдельные ядра нагрузка может быть больше и Oracle эту нагрузку между ядрами не балансирует. Кроме того ядра бывают не полностью независимые, а например по 2 через гипертрейдинг, которые тоже между собой за ресурсы конкурируют. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2016, 09:26 |
|
||
|
Эпическая деградация производительности
|
|||
|---|---|---|---|
|
#18+
aborigen, в моей практике, когда я занимался разработкой на Oracle, очень похожие симптомы были при заполнении TEMP TABLESPACE. Если так, то в качестве быстрого решения можно пробовать в разы увеличить TEMP, и параллельно разбираться с неэффективными запросами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2016, 10:09 |
|
||
|
Эпическая деградация производительности
|
|||
|---|---|---|---|
|
#18+
И ещё одна попытка выложить AWR ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2016, 10:47 |
|
||
|
Эпическая деградация производительности
|
|||
|---|---|---|---|
|
#18+
Koreshaborigen, в моей практике, когда я занимался разработкой на Oracle, очень похожие симптомы были при заполнении TEMP TABLESPACE. Если так, то в качестве быстрого решения можно пробовать в разы увеличить TEMP, и параллельно разбираться с неэффективными запросами. Что-то не в тему. Заполнение TEMP может дать ошибки Unable to extend..... Замедление может дать чересчур активное использование TEMP, но с заполнением это в общем случае не взаимообусловлено. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2016, 10:48 |
|
||
|
Эпическая деградация производительности
|
|||
|---|---|---|---|
|
#18+
Правда, если в системе выставлен RESUMABLE_TIMEOUT, то сессии до того, как получить ошибку переполнения, будут просто зависать на этот таймаут ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2016, 10:59 |
|
||
|
Эпическая деградация производительности
|
|||
|---|---|---|---|
|
#18+
Запрос с sql_id d99wbughxy7yb больше всего ресурсов процессора потребляет и за час не выполнился. Может можно от него избавиться или заменить на другой? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2016, 11:06 |
|
||
|
Эпическая деградация производительности
|
|||
|---|---|---|---|
|
#18+
У меня недавно было, оказалось из-за пары запросов у которых слетел план. Гляньте прям по v$session where status = 'ACTIVE' что за запросы превалируют в момент высокого cpu и проверьте не менялся ли план недавно на более худший. До этого случая был еще один - из-за патчинга в Solarisе, но там system cpu был больше половины. pg_contig_disable=1 помог. http://knowledgebase.progress.com/articles/Article/P147903 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2016, 11:07 |
|
||
|
Эпическая деградация производительности
|
|||
|---|---|---|---|
|
#18+
Melkomyagkii_newbi, Спасибо за совет, но как понять какой раньше был план? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2016, 11:13 |
|
||
|
Эпическая деградация производительности
|
|||
|---|---|---|---|
|
#18+
aabezuglyMelkomyagkii_newbi, Спасибо за совет, но как понять какой раньше был план? EM -> Performance -> Search SQL -> SQL_ID из топа AWR например . Ну и вообще на заглавной странице будут они . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2016, 11:57 |
|
||
|
Эпическая деградация производительности
|
|||
|---|---|---|---|
|
#18+
немного оффтоп, но подскажите, пожалуйста, почему на скрине ТОРа shr от 18m до 27m в то время как судя по awr sga=56g ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2016, 12:33 |
|
||
|
Эпическая деградация производительности
|
|||
|---|---|---|---|
|
#18+
JebrailaabezuglyMelkomyagkii_newbi, Спасибо за совет, но как понять какой раньше был план? EM -> Performance -> Search SQL -> SQL_ID из топа AWR например . Ну и вообще на заглавной странице будут они . Если нет EM или доступа к нему, можно и запросами посмотреть. Я использую следующие. Это вроде истории изменений плана: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. Этот поможет выбрать наилучший из существовавших планов.(правда тут нужно учитывать еще что какой-то мог устареть из-за того что данных стало больше например) Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2016, 13:50 |
|
||
|
Эпическая деградация производительности
|
|||
|---|---|---|---|
|
#18+
Разберитесь, почему запрос с sql_id d99wbughxy7yb выполняется более часа и сильно потребляет процессор. Можете сделать AWR-отчет за прошлый период времени, когда проблем с производительностью не было и посмотреть, что было с этим запросом - как он портеблял ресурсы процессора, какое время выполнялся. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2016, 14:49 |
|
||
|
|

start [/forum/topic.php?fid=52&fpage=184&tid=1886788]: |
0ms |
get settings: |
10ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
68ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
99ms |
get tp. blocked users: |
2ms |
| others: | 246ms |
| total: | 460ms |

| 0 / 0 |
