ReSQL.ru
     
powered by simpleCommunicator - 2.0.48     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Oracle [игнор отключен] [закрыт для гостей] / как избавиться от virtual circuit wait
10 сообщений из 10, страница 1 из 1
как избавиться от virtual circuit wait
    #39128293
niv76
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
niv76
Гость
Всем привет.
Помогите плиз избавиться от virtual circuit wait.
Имеем RAC ORACLE 11.2.0.3.

Проблема проявляется в том что легкие процедуры (одна из них просто устанавливает значение контекстной переменной) время от времени могут выполняться до нескольких секунд (до 2-5% вызовов).

Вот словил один такой вызов, правда здесь был инсерт:


Код: 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.
40.
41.
42.
43.
44.
45.
46.
INSERT INTO MANAGER (MANAGER_ID,DEPARTMENT_ID,LOGIN,MANAGER_PASS,MANAGER_NAME,
  EMAIL,ACCESS_TYPE,CONTACT_INFO,COMMENT_INFO,LVL,DEPUTY_MANAGER_ID) 
VALUES
 (SQN_MANAGER.NEXTVAL,:B4 , :B3 , :B5, :B2 , :B1 , '0', :B6, 
  '', 1, '') RETURNING MANAGER_ID INTO :O0 


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.06       2.38          4          1         15           1
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        2      0.06       2.38          4          1         15           1

Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 65     (recursive depth: 1)

Rows     Row Source Operation
-------  ---------------------------------------------------
      1  LOAD TABLE CONVENTIONAL  (cr=108 pr=6 pw=0 time=2381011 us)
      1   SEQUENCE  SQN_MANAGER (cr=5 pr=0 pw=0 time=55525 us)


Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  row cache lock                                  6        0.00          0.00
  library cache pin                              13        0.00          0.01
  KJC: Wait for msg sends to complete            19        0.00          0.00
  library cache lock                              8        0.00          0.00
  resmgr:cpu quantum                              5        0.09          0.31
  enq: TM - contention                            7        0.00          0.00
  gc cr grant 2-way                               1        0.00          0.00
  db file sequential read                         4        0.00          0.02
  gc current grant 2-way                          2        0.00          0.00
  gc current grant busy                           2        0.00          0.00
  virtual circuit wait                           17        1.85          1.94
  single-task message                             1        0.00          0.00
  SQL*Net message to dblink                       8        0.00          0.00
  SQL*Net message from dblink                     8        0.00          0.00
  DFS lock handle                                 1        0.00          0.00
  rdbms ipc reply                                 2        0.00          0.00
********************************************************************************



На табличке есть ряд тригеров, которые по дблинку синхронизируют изменения в этой табличке с другой базой.
В трейсе 'virtual circuit wait' идут в перемешку с 'SQL*Net message to dblink', вот фрагмент:

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
WAIT #7480694824: nam='SQL*Net message to dblink' ela= 4 driver id=1413697536 #bytes=1 p3=0 obj#=535247 tim=1450101471150313
WAIT #7480694824: nam='virtual circuit wait' ela= 60 circuit#=50 type=2 p3=0 obj#=535247 tim=1450101471150416
WAIT #7480694824: nam='virtual circuit wait' ela= 241 circuit#=50 type=2 p3=0 obj#=535247 tim=1450101471150680
WAIT #7480694824: nam='SQL*Net message from dblink' ela= 67 driver id=1413697536 #bytes=1 p3=0 obj#=535247 tim=1450101471150704
WAIT #7480694824: nam='SQL*Net message to dblink' ela= 3 driver id=1413697536 #bytes=1 p3=0 obj#=535247 tim=1450101471150778
WAIT #7480694824: nam='virtual circuit wait' ela= 278 circuit#=50 type=2 p3=0 obj#=535247 tim=1450101471151093
WAIT #7480694824: nam='virtual circuit wait' ela= 1362 circuit#=50 type=2 p3=0 obj#=535247 tim=1450101471152481
WAIT #7480694824: nam='SQL*Net message from dblink' ela= 87 driver id=1413697536 #bytes=1 p3=0 obj#=535247 tim=1450101471152524
WAIT #7480694824: nam='DFS lock handle' ela= 486 type|mode=1146617861 id1=2194353809 id2=0 obj#=535247 tim=1450101471153103
WAIT #7480694824: nam='KJC: Wait for msg sends to complete' ela= 9 msg=17568829080 dest|rcvr=0 mtype=12 obj#=535247 tim=1450101471153142
WAIT #7480694824: nam='rdbms ipc reply' ela= 58 from_process=123 timeout=900 p3=0 obj#=535247 tim=1450101471153276
WAIT #7480694824: nam='rdbms ipc reply' ela= 1465 from_process=123 timeout=900 p3=0 obj#=535247 tim=1450101471154790
WAIT #7480694824: nam='SQL*Net message to dblink' ela= 4 driver id=1413697536 #bytes=1 p3=0 obj#=535247 tim=1450101471154912
WAIT #7480694824: nam='virtual circuit wait' ela= 100 circuit#=50 type=2 p3=0 obj#=535247 tim=1450101471155073
WAIT #7480694824: nam='virtual circuit wait' ela= 1486 circuit#=50 type=2 p3=0 obj#=535247 tim=1450101471156583
WAIT #7480694824: nam='SQL*Net message from dblink' ela= 105 driver id=1413697536 #bytes=1 p3=0 obj#=535247 tim=1450101471156627
WAIT #7480694824: nam='SQL*Net message to dblink' ela= 4 driver id=1413697536 #bytes=1 p3=0 obj#=535247 tim=1450101471156659
WAIT #7480694824: nam='virtual circuit wait' ela= 66 circuit#=50 type=2 p3=0 obj#=535247 tim=1450101471156783

*** 2015-12-14 13:57:53.013
WAIT #7480694824: nam='virtual circuit wait' ela= 1857026 circuit#=50 type=2 p3=0 obj#=535247 tim=1450101473013832
WAIT #7480694824: nam='SQL*Net message from dblink' ela= 115 driver id=1413697536 #bytes=1 p3=0 obj#=535247 tim=1450101473013903
EXEC #7480694824:c=184012,e=4183905,p=43,cr=1595,cu=17,mis=1,r=1,dep=1,og=1,plh=2510593528,tim=1450101473013991



В подтверждение версии того, что это как-то связано с дблинком говорит, что были вейты во время коммита:

Код: 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.
SQL ID: 8ggw94h7mvxd7
Plan Hash: 0
COMMIT


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        2      0.00       0.00          0          0          0           0
Execute      3      0.00       0.38          0          0         15           0
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        5      0.00       0.38          0          0         15           0

Misses in library cache during parse: 0
Parsing user id: 65     (recursive depth: 1)

Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  log file sync                                   3        0.00          0.02
  SQL*Net message to dblink                       2        0.00          0.00
  virtual circuit wait                            4        0.01          0.01
  SQL*Net message from dblink                     2        0.00          0.00
  resmgr:cpu quantum                              2        0.19          0.33
  rdbms ipc reply                                 2        0.00          0.00
********************************************************************************



obj#=535247 из строчки virtual circuit wait показывавает на один из индексов таблички MANAGER.
Администраторы говорят что проблем с шаред серверами и прочими диспатчерами нет.

Код: plsql
1.
2.
3.
4.
5.
6.
7.
INST_ID STATUS COUNT(STATUS)
1 EXEC 5
1 WAIT(COMMON) 21
1 WAIT(RECEIVE) 44
2 EXEC 2
2 WAIT(COMMON) 20
2 WAIT(RECEIVE) 28



Если посмотреть авр на базу, то 'virtual circuit wait' в топах на первом месте с большим отрывом:

Код: plsql
1.
2.
3.
4.
5.
Event                 	Waits	%Time -outs	Total Wait Time (s)	Avg wait (ms)	Waits /txn	% DB time
virtual circuit wait	251,467	2	        172,592	               686            	2.67           	109.17
direct path read    	83,138	0	            571	                7               0.88          	0.36
db file sequential read	116,276	0	            442	                4	        1.24           	0.28
log file sync	        60,356	0	            301	                5              	0.64           	0.19



на всякий случай присоединяю трейс файл и авр репорт:
...
Рейтинг: 0 / 0
15.12.2015, 12:05
| Ответить | Цитировать | Написать  
как избавиться от virtual circuit wait
    #39128294
niv76
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
niv76
Гость
здесь авр:
...
Рейтинг: 0 / 0
15.12.2015, 12:06
| Ответить | Цитировать | Написать  
как избавиться от virtual circuit wait
    #39128569
wurdu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
wurdu
Участник
niv76Администраторы говорят что проблем с шаред серверами и прочими диспатчерами нет.
Я бы так не сказал, т.к. в AWR мы видим 96.92% busy в Shared Servers Utilization.
И если они ждут WAIT(RECEIVE), то возможно проблема в этом: Shared Servers and Automatic Workarea Management .
Также это и другое описано тут: Troubleshooting: Virtual Circuit Waits (Doc ID 1415999.1).
...
Рейтинг: 0 / 0
15.12.2015, 14:21
| Ответить | Цитировать | Написать  
как избавиться от virtual circuit wait
    #39128602
ora601
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ora601
Участник
niv76,

кину еще ссылку на блог Игоря https://iusoltsev.wordpress.com/2011/03/26/virtual-circuit-wait-huge-fetches/, про влияние arraysize на эти ожидания, и то что значительная часть этих ожиданий idle.
...
Рейтинг: 0 / 0
15.12.2015, 14:38
| Ответить | Цитировать | Написать  
как избавиться от virtual circuit wait
    #39129127
niv76
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
niv76
Гость
wurduniv76Администраторы говорят что проблем с шаред серверами и прочими диспатчерами нет.
Я бы так не сказал, т.к. в AWR мы видим 96.92% busy в Shared Servers Utilization.


Спасибо.
Сори. С авром обманул. Это старый авр, после него мы добавляли кол-во шаред серверов и эта статистика поменялась, но кол-во virtual circuit wait все равно очень высокое .

Читал доку:

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
Identifying Contention Using the Dispatcher-Specific Views
The following views provide dispatcher performance statistics:
■ V$DISPATCHER: general information about dispatcher processes
■ V$DISPATCHER_RATE: dispatcher processing statistics
The V$DISPATCHER_RATE view contains current, average, and maximum dispatcher
statistics for several categories. Statistics with the prefix CUR_ are statistics for the
current sample. Statistics with the prefix AVG_ are the average values for the statistics
after the collection period began. Statistics with the prefix MAX_ are the maximum
values for these categories after statistics collection began.
To assess dispatcher performance, query the V$DISPATCHER_RATE view and compare
the current values with the maximums. If your present system throughput provides
adequate response time and current values from this view are near the average and
less than the maximum, then you likely have an optimally tuned shared server
environment.
If the current and average rates are significantly less than the maximums, then
consider reducing the number of dispatchers. Conversely, if current and average rates
are close to the maximums, then you might need to add more dispatchers. A general
rule is to examine V$DISPATCHER_RATE statistics during both light and heavy system
use periods. After identifying your shared server load patterns, adjust your
parameters accordingly.



У нас похоже "the current and average rates are significantly less than the maximums". Думаю стоит ли пробовать
уменьшить кол-во диспатчеров, как тут советуют. Не понимаю этот совет. Что это может дать... Можете объяснить?

Вот фрагмент данных:

CUR_MSG_RATECUR_SVR_BUF_RATECUR_SVR_BYTE_RATECUR_SVR_BYTE_PER_BUFMAX_MSG_RATEMAX_SVR_BUF_RATEMAX_SVR_BYTE_RATEMAX_SVR_BYTE_PER_BUFAVG_MSG_RATEAVG_SVR_BUF_RATEAVG_SVR_BYTE_RATEAVG_SVR_BYTE_PER_BUF231813852776112189101439697076371215116917923514854852148451207791853033121176140611000160641819902248182602166969914933522862142924790276371220159997430751871423403198673263712801519230000133753919897808182101141321366227114267326219909152606415123362910363641184543199341253033702013112538793263445873201792853010191204935230006972872008570530101511017765358073666434272024411434408121314264910773369460765229481827013941329111416321821077200162355477181528789038377352155517443328182161162518


Прикреплю актуальные авр с обеих нод (время проблемного инсерта попало в АВР).
...
Рейтинг: 0 / 0
15.12.2015, 20:13
| Ответить | Цитировать | Написать  
как избавиться от virtual circuit wait
    #39129129
niv76
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
niv76
Гость
Авр со второй ноды
...
Рейтинг: 0 / 0
15.12.2015, 20:14
| Ответить | Цитировать | Написать  
как избавиться от virtual circuit wait
    #39129134
niv76
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
niv76
Гость
данные по системным вьюшкам в файлах (последняя цифра в имени файла = номеру запроса):

--1
SELECT t.*, DECODE(TOTALQ, 0, 'No Requests',
WAIT/TOTALQ || ' HUNDREDTHS OF SECONDS') "AVERAGE WAIT TIME PER REQUESTS"
FROM gV$QUEUE t
WHERE TYPE = 'COMMON';


--2
select * from gV$SHARED_SERVER_MONITOR ;


--3
SELECT s.*,
(BUSY/(BUSY + IDLE)) * 100 "%TIME BUSY"
FROM gV$SHARED_SERVER s;


--4
select * FROM gV$SHARED_SERVER_MONITOR;


--5
select * from gV$CIRCUIT;


--6
select * from gV$DISPATCHER;


--7
select * from gV$DISPATCHER_CONFIG;


--8
select * from gV$DISPATCHER_RATE;


--9
select * from gV$SESSION;
...
Рейтинг: 0 / 0
15.12.2015, 20:20
| Ответить | Цитировать | Написать  
как избавиться от virtual circuit wait
    #39129789
wurdu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
wurdu
Участник
Я бы проверил в начале что это не Bug 11895446 - Excessive 'virtual circuit wait' with shared servers due to instance locks held in RAC environment (Doc ID 11895446.8).
Вообще конечно грустно все это выглядит. Два ядра, причем боюсь что виртуальные. CPU перегружены, ресурс менеджер душит шаред сервера. И еще зачем-то рак.
...
Рейтинг: 0 / 0
16.12.2015, 14:17
| Ответить | Цитировать | Написать  
как избавиться от virtual circuit wait
    #39129868
niv76
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
niv76
Гость
wurduЯ бы проверил в начале что это не Bug 11895446 - Excessive 'virtual circuit wait' with shared servers due to instance locks held in RAC environment (Doc ID 11895446.8).
Вообще конечно грустно все это выглядит. Два ядра, причем боюсь что виртуальные. CPU перегружены, ресурс менеджер душит шаред сервера. И еще зачем-то рак.
Спасибо большое, wurdu.
Да, похоже что из-за него.
У нас ORACLE 11.2.0.3

Versions confirmed as being affected
11.2.0.3
11.2.0.2

Fixed:

The fix for 11895446 is first included in
12.1.0.1 (Base Release)
11.2.0.4 (Server Patch Set)


На выходных админы будут пробовать патчить сервер, посмотрим...
...
Рейтинг: 0 / 0
16.12.2015, 15:23
| Ответить | Цитировать | Написать  
как избавиться от virtual circuit wait
    #39144756
niv76
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
niv76
Гость
пропатчили базу. Помогло. Кол-во вейтов осталось примерно то же. Но среднее время вейта упало на одной ноде примерно в 25 раз, на другой примерно в 50 раз.
Спасибо большое за помощь. :)
...
Рейтинг: 0 / 0
11.01.2016, 16:42
| Ответить | Цитировать | Написать  
10 сообщений из 10, страница 1 из 1
Форумы / Oracle [игнор отключен] [закрыт для гостей] / как избавиться от virtual circuit wait
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru             Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=52&gotonew=1&tid=1889191]:
 0ms
get settings:
 10ms
get forum list:
 14ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 68ms
get topic data:
 13ms
get first new msg:
 8ms
get forum data:
 3ms
get page messages:
 58ms
get tp. blocked users:
 1ms
others: 14ms
total:  197ms
созд. / загр.: 197ms
x
x
Закрыть


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