|
enq: TX - contention на обычных селектах
|
|||
---|---|---|---|
#18+
Добрый день. На базе ежедневно на определенной части операций начинают массово лезть события типа enq: TX - contention. ХЗ насколько это важно, но достоверно известно, что сессия блокер находится в ожидании либо SQL*Net message from dblink, либо log file sync Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22.
Есть догадки, что проблема связана с использованием DBLINKов. Подскажите в какую сторону копать, может кто сталкивался с подобным? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2019, 13:06 |
|
enq: TX - contention на обычных селектах
|
|||
---|---|---|---|
#18+
feagor, Код: plsql 1. 2. 3. 4. 5. 6.
... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2019, 13:10 |
|
enq: TX - contention на обычных селектах
|
|||
---|---|---|---|
#18+
feagor, в момент данных событий крутятся многопоточно однотипные операции. т.е потоки блокируют друг друга ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2019, 13:17 |
|
enq: TX - contention на обычных селектах
|
|||
---|---|---|---|
#18+
SELECT ... FOR UPDATE ? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2019, 13:56 |
|
enq: TX - contention на обычных селектах
|
|||
---|---|---|---|
#18+
Вячеслав Любомудров, В первую очередь проверяли, такого рода запросы отсутствуют во время проблем отсутствуют. А были бы - скорее всего вызывали ENQ - TX Row lock contention из APPLICATION ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2019, 14:17 |
|
enq: TX - contention на обычных селектах
|
|||
---|---|---|---|
#18+
ничего не поняла.. какая разница, чем занята блокирующая сессия? ты покажи что делают те, что ожидают блокировку ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2019, 14:18 |
|
enq: TX - contention на обычных селектах
|
|||
---|---|---|---|
#18+
DВА, делают обычные селекты к таблицам топ 1 Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.
... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2019, 14:25 |
|
enq: TX - contention на обычных селектах
|
|||
---|---|---|---|
#18+
DВА, топ 2 Код: plsql 1. 2. 3. 4. 5. 6. 7.
топ3 Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2019, 14:29 |
|
enq: TX - contention на обычных селектах
|
|||
---|---|---|---|
#18+
feagor, Выложите ashdump или хотя бы ash report. Вы проверили объекты на которых это ожидание возникает? Не какой-нибудь аудит или прочая рекурсивная фигня? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2019, 14:39 |
|
enq: TX - contention на обычных селектах
|
|||
---|---|---|---|
#18+
А распределенные транзакции есть ? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2019, 14:42 |
|
enq: TX - contention на обычных селектах
|
|||
---|---|---|---|
#18+
xtender, проверь почту ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2019, 14:47 |
|
enq: TX - contention на обычных селектах
|
|||
---|---|---|---|
#18+
DВА, да, есть ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2019, 14:48 |
|
enq: TX - contention на обычных селектах
|
|||
---|---|---|---|
#18+
feagor, ага, вижу, DBA сразу угадала - ваш случай: https://nigelnoble.wordpress.com/2013/07/12/enq-tx-contention-on-select-with-a-large-buffer-cache-and-2pc/ Что у вас со стендбаем? Он далеко? В общем, оптимизируйте распределенные транзакции и решайте проблему с медленным log file sync ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2019, 15:19 |
|
enq: TX - contention на обычных селектах
|
|||
---|---|---|---|
#18+
xtender, видел эту статью. в статье проблема была в лаге между австралией британией в 200-300мс,если я правильно всё понял, у нас же сервера стоят рядышком в одной локалке ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2019, 15:28 |
|
enq: TX - contention на обычных селектах
|
|||
---|---|---|---|
#18+
Насколько я понял, из статьи следует вывод, что commit_point_strength надо выставлять на БД с наибольшим размером кеша (точнее, соотношения испачканных блоков к размеру кеша)? Ну, типо, т.к. размер кеша больше, из 10% списка испачканных буферов фактически большее количество остается "грязными" в памяти -- т.е. к ним применяется commit-cleanout А т.к. узел с наибольшим commit_point_strength выполняет коммит первым и, вследствии этого, никогда не выступает в виде "сомнительной распределенной транзакции", то и блокировать никого не будет Или надо тупо уменьшать кеш для всех? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2019, 15:54 |
|
enq: TX - contention на обычных селектах
|
|||
---|---|---|---|
#18+
feagor, не столько важно насколько "рядышком", важно насколько быстро двухфазный коммит проходит :) а у вас там еще и перегрузка по cpu ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2019, 16:08 |
|
enq: TX - contention на обычных селектах
|
|||
---|---|---|---|
#18+
Вячеслав Любомудров, мне в принципе не кажется надежным играть с этим, т.к. слишком много факторов и даже кол-во изменяемых данных на разных базах часто может "плавать" ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2019, 16:12 |
|
enq: TX - contention на обычных селектах
|
|||
---|---|---|---|
#18+
Вячеслав Любомудров, Кстати, в то время, как на локальной базе нагрузка составляет более 100активных сессий на удаленной базе, в это время среднее количество активных сессий не более 10(нагрузка практически отсутствует). Так и не понял суть параметра commit_point_strength. но бурлесон пишет Hence, you will want the commit_point_strength to be the highest on the database instance that contains the most data. Сейчас на обоих базах стоит значение 1. Может в качестве эксперимента попробовать его увеличить на основной базе? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2019, 16:16 |
|
enq: TX - contention на обычных селектах
|
|||
---|---|---|---|
#18+
Обычно, смысл этого параметра: чем критичней данный -- тем выше Ибо с максимальным значением данная нода становится координатором (там другая должность на самом деле) транзакции и никогда не оставит данные (на этой ноде) в состоянии "in-doubt transaction", т.е. блокированными для чтения. Но, естественно, чем больше времени занимает ее локальный коммит (включая тот самый commit-cleanout), тем дольше в подвешенном состоянии находятся остальные узлы. Но их время "подвешенного" состояния еще определяется и скоростью выполнения коммита (и, опять же commit-cleanout, оказывается, это существенно ) на всех остальных узлах Как-то так ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2019, 16:27 |
|
enq: TX - contention на обычных селектах
|
|||
---|---|---|---|
#18+
Вячеслав Любомудров, а если на обоих базах значение одинаковое и равно =1, кто будет координатором транзакции (там другая должность на самом деле)? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2019, 16:35 |
|
enq: TX - contention на обычных селектах
|
|||
---|---|---|---|
#18+
Насколько помню, тот где сессия изменяет изменяет "чужие" (по линку) данные. Свои при этом может и не менять, но она все равно имеет открытую RW транзакцию ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2019, 16:42 |
|
enq: TX - contention на обычных селектах
|
|||
---|---|---|---|
#18+
Вячеслав Любомудров, То есть если db1 вызывает по линку процедуру в db2, которая в db2(локально) меняет данные, то управлять транзакцией будет db1? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2019, 16:47 |
|
enq: TX - contention на обычных селектах
|
|||
---|---|---|---|
#18+
Для потомков Если db1 вызывает по линку процедуру в db2, которая в db2(локально) меняет данные, то управлять транзакцией будет db1? Управляла по всей видимости DB2. Блокировки на чтение enq: TX - contention шли в DB1, как показано в первом сообщении. После выставления параметра commit_point_strength на DB1 = 2(было на обоих = 1). События сменили место дислокации с DB1 на DB2 (как тут загруженные картинки нормально прикладывать) В итоге вместо блокировок по 100+ активных сессий на основной базе имеем блокировки на 2,5 активных сессий на вспомогательной базе. Таким образом проблема решена. Огромное спасибо Xtender, Вячеслав Любомудров, DBA ... |
|||
:
Нравится:
Не нравится:
|
|||
20.04.2019, 17:44 |
|
enq: TX - contention на обычных селектах
|
|||
---|---|---|---|
#18+
feagor, одно "но" - если изменится пропорция нагрузки или кол-ва изменений, то вы опять попадете в ту же ситуацию, поэтому в таких случаях правильнее всего дробить операции на меньшие ... |
|||
:
Нравится:
Не нравится:
|
|||
21.04.2019, 00:15 |
|
enq: TX - contention на обычных селектах
|
|||
---|---|---|---|
#18+
xtender, Да, я вроде понимаю этот момент. Но такого непосредственно с 2 этими базами на практике быть не может, одна основная с 54 ядрами, вторая можно сказать "вспомогательная", с 8 ядрами. Нагрузки более 15 активных сессий на db2 не бывает. Конечно, будем наблюдать за поведением. Но пока все выглядит так, что использование параметра решило нашу проблему. Тюнить сами транзакции - это конечно дело доброе, но крайне трудозатратное, и не всегда реализуемое. Проблемы производительности у нас чаще всего в бизнес-логике операций, а ответственные далеко не всегда готовы пересматривать эту логику в угоду производительности ... |
|||
:
Нравится:
Не нравится:
|
|||
21.04.2019, 18:19 |
|
|
start [/forum/topic.php?fid=52&fpage=78&tid=1882559]: |
0ms |
get settings: |
12ms |
get forum list: |
15ms |
check forum access: |
5ms |
check topic access: |
5ms |
track hit: |
39ms |
get topic data: |
14ms |
get forum data: |
3ms |
get page messages: |
89ms |
get tp. blocked users: |
2ms |
others: | 16ms |
total: | 200ms |
0 / 0 |