Деградация производительности с latch free: Result Cache: RC Latch / Oracle

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / Oracle [игнор отключен] [закрыт для гостей] / Деградация производительности с latch free: Result Cache: RC Latch

12 сообщений из 12, страница 1 из 1

Деградация производительности с latch free: Result Cache: RC Latch

#39913214

feagor

Гость

Добрый день.
У клиента возникла проблема с падением производительности на базе.
Осмотр AWR отчётов показал проблему с событиями latch free и enq: RC - Result Cache: Contention

latch free шли с p2=665, что по v$latch говорим нам об Result Cache: RC Latch

Код: plaintext

1.
2.
3.

select name from v$latch where latch#=665;
NAME
----------------------------------------------------------------
Result Cache: RC Latch

Версия 12.2

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.

SELECT * FROM v$version;
BANNER                                                                               CON_ID
-------------------------------------------------------------------------------- ----------
Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production              0
PL/SQL Release 12.2.0.1.0 - Production                                                    0
CORE	12.2.0.1.0	Production                                                                0
TNS for Linux: Version 12.2.0.1.0 - Production                                            0
NLSRTL Version 12.2.0.1.0 - Production                                                    0

далее анализ v$result_cache_objects показывает нам наиболее используемые объекты

Код: plaintext

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.

SQL> 
select namespace, status, name,
count(*) res_cnt,
type,
round(avg(scan_count)) avg_scan_cnt,
round(max(scan_count)) max_scan_cnt,
round(sum(block_count)) tot_blk_cnt
from v$result_cache_objects
where type = 'Result'
group by namespace, name, status,type
order by number_of_results desc;
NAMESPACE  STATUS    NAME                                                                             RES_CNT TYPE       AVG_SCAN_CNT MAX_SCAN_CNT TOT_BLK_CNT
---------- --------- -------------------------------------------------------------------------------- ----------------- ---------- ------------ ------------ -----------
PLSQL      Invalid   ""."C_PKGPRM"::11."FGETVALPRM_CACHED"#6a82c8303b523720 #64                              4082 Result                1          266        4098
PLSQL      Published ""."FCHKUSRTRN"::8."FCHKUSRTRN"#3048d2af80817a01 #1                                     1966 Result             1831        39478        1966
PLSQL      Published ""."C_PKGPRM"::11."FGETVALPRM_CACHED"#6a82c8303b523720 #64                              1839 Result               11         3117        1849
PLSQL      Published ""."C_PKGBS_DOM"::11."DLONGNAME"#be11c3b85ca2b634 #91                                    627 Result           372720     82932719         627
PLSQL      Published ""."U_PKGCOUNTRY"::11."FNAME"#8287fb8db4848443 #191                                      376 Result            13232      1400699         376
PLSQL      Published ""."C_PKGBS_DOM"::11."DVAL_IS_VALID"#a0be020bae7061ea #179                               328 Result          2837017    106614424         328
PLSQL      Published ""."U_PKGMLBATCHIMP"::11."FGETOPRNAME"#cf4e80ebbef64bcd #1256                            219 Result             9326       128737         219
PLSQL      Published ""."C_PKGBS_DOM"::11."DVALNAME_VNAME"#453f25eeddf41947 #46                               197 Result            37393      4381939         197
PLSQL      Published ""."C_PKGBS_DOM"::11."DNAME"#453f25eeddf41947 #109                                       193 Result          4586924    486923526         193
PLSQL      Published ""."C_PKGBS_SCEN"::11."FGETSCENNAME"#24b84837171a933d #65                                191 Result            28137      1027249         191
PLSQL      Published ""."C_PKGPRM"::11."FCODE2ID"#32fb3b6bdac49c05 #3                                         142 Result               24         1356         142
PLSQL      Published ""."C_PKGDECTBL"::11."FDECISIONLIST"#dfc3af67eb0efbf9 #944                               135 Result            29967      2485691         135
PLSQL      Published ""."C_PKGBS_SCEN"::11."FGETSCENNORD"#39201a60d63e72b8 #28                                121 Result           100429      1349060         121
PLSQL      Published ""."C_PKGBS_SCEN"::11."FGETSCENCODE"#3265457c9243f577 #47                                111 Result            49017      1137324         111
PLSQL      Published ""."C_PKGDECTBL"::11."FTBLNAME"#3265457c9243f577 #509                                     26 Result           806518      4751476          26
PLSQL      Published ""."U_PKG_MAILOPER"::11."FSHOWF22"#963b7b52b7a7c411 #182                                  21 Result          6351507    125523452          21
PLSQL      Published ""."C_PKGDECTBL"::11."FTBLID"#2300a0448782c31d #480                                       20 Result           978829      4751498          20

Статистика и размер RC

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.

select name, value from v$result_cache_statistics;--197946962
NAME                                                                             VALUE
-------------------------------------------------------------------------------- --------------------------------------------------------------------------------
Block Size (Bytes)                                                               1024
Block Count Maximum                                                              183520
Block Count Current                                                              89600
Result Size Maximum (Blocks)                                                     9176
Create Count Success                                                             280381075
Create Count Failure                                                             0
Find Count                                                                       1161894806
Invalidation Count                                                               198091387
Delete Count Invalid                                                             280291746
Delete Count Valid                                                               0
Hash Chain Length                                                                1-3
Find Copy Count                                                                  1153231846
Latch (Share)                                                                    0

Собственно вопрос - мне не до конца понятно из-за чего вылазят эти ожидания latch free и что с ними делать.
Насколько я понимаю LATСH_FREE из OTHERS с p2=Result Cache: RC Latch говорит о том, что кэш переполнен. И причина - либо маленький размер RC, либо неправильное использование механизма кэширование запросов, когда кэшируются запросы, результаты которых после выполнения повторно либо не запрашиваются вообще, либо запрашиваются в малом количестве.
Но судя по статистике RC видно, что он заполнен лишь наполовину, тогда откуда ожидания?
И еще отдельный вопрос - что может вызывать инвалидацию? так как те функции, например "C_PKGPRM"."FGETVALPRM_CACHED" работает с таблицей-справочником, которая практически никогда не меняется, но тем не менее, видно что большая часть значений инвалидировалась.

Понимаю, что выключение RC по-большому счёту поможет, но хотелось бы разобраться более детально

...

Рейтинг:

0 / 0

13.01.2020, 13:59

| Ответить | Цитировать | Написать

Деградация производительности с latch free: Result Cache: RC Latch

#39913352

Sayan Malakshinov

Модератор форума

Откуда: Мск

Сообщения: 5 731

Рейтинг: 0 / 0

feagor,

Видно же что инвалидаций вагон.

...

Рейтинг:

0 / 0

13.01.2020, 18:27

| Ответить | Цитировать | Написать

Деградация производительности с latch free: Result Cache: RC Latch

#39913440

SQL*Plus

Участник

Откуда: Россия, Москва

Сообщения: 8 665

Рейтинг: 0 / 0

feagor

Код: plaintext

1.
2.

NAMESPACE  STATUS    NAME                                                                             RES_CNT TYPE       AVG_SCAN_CNT MAX_SCAN_CNT TOT_BLK_CNT
---------- --------- -------------------------------------------------------------------------------- --------- -------- ---------- ------------ ------------ -----------
PLSQL      Invalid   ""."C_PKGPRM"::11."FGETVALPRM_CACHED"#6a82c8303b523720 #64                        4082 Result                1          266        4098

И еще отдельный вопрос - что может вызывать инвалидацию?
так как те функции, например "C_PKGPRM"."FGETVALPRM_CACHED" работает с таблицей-справочником,
которая практически никогда не меняется, но тем не менее,
видно что большая часть значений инвалидировалась.

Предположим, что в RC было 4082 значения, связанных с таблицей-справочником.
Потом в этой таблице изменили одно поле в одной строке и сделали COMMIT.
Что произойдет со значениями в Result Cache?

...

Рейтинг:

0 / 0

14.01.2020, 01:13

| Ответить | Цитировать | Написать

Деградация производительности с latch free: Result Cache: RC Latch

#39913511

feagor

Гость

SQL*Plus Потом в этой таблице изменили одно поле в одной строке и сделали COMMIT.
Что произойдет со значениями в Result Cache?
понятно что инвалидируются, но таблица -справочник, значения в ней меняются ну пусть будет 10 раз в день(но я еще проверю), а инвалидация идёт постоянно. Могут ли быть какие-то другие причины инвалидации, кроме очевидного изменения данных в источнике ?
чем принципиально отличаются ожидания enq: RC - Result Cache: Contention и latch free Result Cache: RC Latch ?

...

Рейтинг:

0 / 0

14.01.2020, 10:21

| Ответить | Цитировать | Написать

Деградация производительности с latch free: Result Cache: RC Latch

#39913547

SQL*Plus

Участник

Откуда: Россия, Москва

Сообщения: 8 665

Рейтинг: 0 / 0

feagor,

См. ноту
Troubleshooting High 'Latch Free' Waits with Contention on 'Result Cache: RC Latch' (Doc ID 2143739.1)

Есть много других нот и багов.

Наилучший вариант решения проблемы:
Обратитесь в техподдержку My Oracle Support (MOS).

...

Рейтинг:

0 / 0

14.01.2020, 11:26

| Ответить | Цитировать | Написать

Деградация производительности с latch free: Result Cache: RC Latch

#39914385

feagor

Гость

SQL*Plus,
Начал смотреть дальше.
Сбросил кэш, увеличил со 150 мб до 900
alter system set RESULT_CACHE_MAX_SIZE=900M

мониторю

Код: plsql

select name, value from v$result_cache_statistics;

значение Block Count Current постепенно увеличивается, инвалиды по той таблице-справочнику не вылазит

как только значение Block Count Current достигает 89600(85мб)
начинают лететь события типа latch:free

Таким образом всё же похоже, что заканчивается место под RC, но RC упорно пишет, что удаленных результатов из-за нехватки памяти нет.Delete Count Valid = 0
Почему количество результатов ограничено 85мб, хотя я выставляю параметром 900мб?

...

Рейтинг:

0 / 0

15.01.2020, 15:35

| Ответить | Цитировать | Написать

Деградация производительности с latch free: Result Cache: RC Latch

#39914398

Sayan Malakshinov

Модератор форума

Откуда: Мск

Сообщения: 5 731

Рейтинг: 0 / 0

feagor,

feagor

Могут ли быть какие-то другие причины инвалидации, кроме очевидного изменения данных в источнике ?

например:
1. select for update из таблицы, от которой зависит с последующим commit; без изменений
2. изменения в таблице на которую есть FK с on delete cascade в случае, если поле FK не проиндексировано. 12930575
Помимо этого встречал проблему с инвалидацией из-за триггера, но давно было и деталей уже не помню. Возможно, Андрей Серапионович Николаев из РДТех еще помнит.

...

Рейтинг:

0 / 0

15.01.2020, 15:52

| Ответить | Цитировать | Написать

Деградация производительности с latch free: Result Cache: RC Latch

#39914399

Sayan Malakshinov

Модератор форума

Откуда: Мск

Сообщения: 5 731

Рейтинг: 0 / 0

xtender

Помимо этого встречал проблему с инвалидацией из-за триггера

из того, что всплыло в памяти: функция с RC вызывалась в триггере к совершенно другой таблице и неожиданная инвалидация безо всяких DML происходила только под большой нагрузкой.

...

Рейтинг:

0 / 0

15.01.2020, 15:54

| Ответить | Цитировать | Написать

Деградация производительности с latch free: Result Cache: RC Latch

#39914449

Elic

Участник

Сообщения: 30 360

Рейтинг: 0 / 0

feagor

Могут ли быть какие-то другие причины инвалидации, кроме очевидного изменения данных в источнике ?

Компиляция.

...

Рейтинг:

0 / 0

15.01.2020, 17:11

| Ответить | Цитировать | Написать

Деградация производительности с latch free: Result Cache: RC Latch

#39914548

SQL*Plus

Участник

Откуда: Россия, Москва

Сообщения: 8 665

Рейтинг: 0 / 0

feagor

SQL*Plus,
Начал смотреть дальше.
Сбросил кэш, увеличил со 150 мб до 900
alter system set RESULT_CACHE_MAX_SIZE=900M

мониторю

Код: plsql

select name, value from v$result_cache_statistics;

RESULT_CACHE_MAX_RESULT = ?

...

Рейтинг:

0 / 0

15.01.2020, 19:55

| Ответить | Цитировать | Написать

Деградация производительности с latch free: Result Cache: RC Latch

#39914641

feagor

Гость

SQL*Plus,

5% по дефолту

...

Рейтинг:

0 / 0

16.01.2020, 08:58

| Ответить | Цитировать | Написать

Деградация производительности с latch free: Result Cache: RC Latch

#39914889

SQL*Plus

Участник

Откуда: Россия, Москва

Сообщения: 8 665

Рейтинг: 0 / 0

feagor

SQL*Plus,

5% по дефолту

22058620

...

Рейтинг:

0 / 0

16.01.2020, 16:03

| Ответить | Цитировать | Написать

12 сообщений из 12, страница 1 из 1

Форумы / Oracle [игнор отключен] [закрыт для гостей] / Деградация производительности с latch free: Result Cache: RC Latch

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

Введите код, изображенный на картинке. Если код нечитаемый, кликните картинку, чтобы загрузить другой вариант.

Отправляя сообщение, я выражаю свое согласие с правилами форума и принимаю пользовательское соглашение.

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?fid=52&msg=39914449&tid=1881659]:	0ms
get settings:	9ms
get forum list:	14ms
check forum access:	4ms
check topic access:	4ms
track hit:	50ms
get topic data:	10ms
get forum data:	2ms
get page messages:	51ms
get tp. blocked users:	1ms
others:	15ms

total:	160ms