|
latch free: transaction branch allocation?
|
|||
---|---|---|---|
#18+
Господа, доброе время суток! Подскажите пожалуйста, как понять, что вызвало событие ожидания latch free: transaction branch allocation? Проблема: В рандомный момент времени возникла резкая деградация производительности инстанса, и утилизация CPU. Load Average более 100. В AWR вижу, что 90% DB-time тратится на latch free , по ASH-отчету совершенно четко виден конкретный вид лидирующего ожидания latch free – а именно transaction branch allocation . Есть номер защелки из ASH Top Event, как понять, что его вызвало? Из v$latch получил адрес, но что делать дальше не знаю. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9.
Спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2019, 15:27 |
|
latch free: transaction branch allocation?
|
|||
---|---|---|---|
#18+
Лучше весь AWR выложить. Также почитай тут Thousands of active sessions waiting on latch free in relation to 'transaction branch allocation' (Doc ID 2018260.1) -> Bug 20130575 - high contention on transaction branch allocation (Doc ID 20130575.8) ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2019, 16:31 |
|
latch free: transaction branch allocation?
|
|||
---|---|---|---|
#18+
Вот AWR. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2019, 17:10 |
|
latch free: transaction branch allocation?
|
|||
---|---|---|---|
#18+
На что стоит обратить внимание: 1. Хост в этом AWR не перегружен, из 20 CPUs примерно 6 в секунду использовались, но это усредненные значения. Надо посмотреть что было когда load average доходил до 100. Например, в OS Watcher logs. Sys% CPU выглядит высоким, лежит ли SGA в huge pages? 2. Среднее время ожидания "latch free" 6 сек, это достаточно много. Пиковые значения были 16-32 сек. В таких случаях стоит снять hang analyze или system state dump и там смотреть, кто держит латч такое долгое время. Как вариант можно посмотреть в ASH, есть шанс найти блокера там. Все эти "latch free" могли стать жертвами какого-нибудь "latch: shared pool", которые тоже доходили до 8-16 сек. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2019, 18:18 |
|
latch free: transaction branch allocation?
|
|||
---|---|---|---|
#18+
Alexander Anokhinлежит ли SGA в huge pages? Нет. Alexander AnokhinНапример, в OS Watcher logs. Оно походу не стоит на сервере. Надо посмотреть. Нужно смотреть логи именно в период проблемы? В ADDM есть несколько запросов с Waiting for event "latch free", а так же: Код: 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. 34. 35. 36. 37. 38. 39.
Дополнительно приложил ASH и ADDM. Вероятно это не бага, надо просто тюнить запросы? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.11.2019, 12:03 |
|
latch free: transaction branch allocation?
|
|||
---|---|---|---|
#18+
В ADDM в данном случае ничего полезного. ASH сильно широкий период - 7 часов. Когда я упоминал поиск блокера в ASH, я имел ввиду смотреть в DBA_HIST_ACTIVE_SESS_HISTORY что делали блокирующие сессии. p4r53cОно походу не стоит на сервере. Надо посмотреть. Нужно смотреть логи именно в период проблемы? Да, надо смотреть период проблемы. Ожидания латчей, которые предполагаются быть очень короткими и не выходить в топ, могут становиться видны в результате перегрузки (overload) сервера, когда в следствие нехватки CPU процессы вынуждены спать дольше, там где спать не предполагается, удерживая чувствительные ресурсы типа латчей. Особенно там, где код удерживающий латч не оптимальный, как в случае Bug 20130575. В твоём AWR не видно проблем с хостом, но если как ты говоришь load average доходил до 100, то надо смотреть в OS Watcher logs или sar, как хост себя чувствовал в эти периоды, почему load average был такой высокий, что запускалось и т.д. Стоит взять такой же AWR за другой день, где предполагается похожая нагрузка и сравнить. Также среднее время "latch free" - 6 сек - очень высокое. Это говорит не в пользу нехватки CPU, а скорее указывает что была некая блокирующая сессия, которая могла висеть по совсем другим причинам. Стоит заглянуть в трейс файл DIAG процесса и проверить не сделал ли Oracle hang analyze dump сам. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.11.2019, 16:34 |
|
|
start [/forum/topic.php?fid=52&fpage=62&tid=1881915]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
34ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
32ms |
get tp. blocked users: |
1ms |
others: | 13ms |
total: | 123ms |
0 / 0 |