Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
 как избавиться от virtual circuit wait  [new]
niv76
Member

Откуда: Киев
Сообщений: 115
Всем привет.
Помогите плиз избавиться от virtual circuit wait.
Имеем RAC ORACLE 11.2.0.3.

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

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


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', вот фрагмент:

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


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

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.
Администраторы говорят что проблем с шаред серверами и прочими диспатчерами нет.

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' в топах на первом месте с большим отрывом:

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


на всякий случай присоединяю трейс файл и авр репорт:

К сообщению приложен файл (trace.zip - 45Kb) cкачать
15 дек 15, 12:05    [18561834]     Ответить | Цитировать Сообщить модератору
 Re: как избавиться от virtual circuit wait  [new]
niv76
Member

Откуда: Киев
Сообщений: 115
здесь авр:

К сообщению приложен файл (awrrpt_1_35064_35065.zip - 109Kb) cкачать
15 дек 15, 12:06    [18561838]     Ответить | Цитировать Сообщить модератору
 Re: как избавиться от virtual circuit wait  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
niv76
Администраторы говорят что проблем с шаред серверами и прочими диспатчерами нет.

Я бы так не сказал, т.к. в AWR мы видим 96.92% busy в Shared Servers Utilization.
И если они ждут WAIT(RECEIVE), то возможно проблема в этом: Shared Servers and Automatic Workarea Management.
Также это и другое описано тут: Troubleshooting: Virtual Circuit Waits (Doc ID 1415999.1).
15 дек 15, 14:21    [18562786]     Ответить | Цитировать Сообщить модератору
 Re: как избавиться от virtual circuit wait  [new]
ora601
Member

Откуда:
Сообщений: 750
niv76,

кину еще ссылку на блог Игоря https://iusoltsev.wordpress.com/2011/03/26/virtual-circuit-wait-huge-fetches/, про влияние arraysize на эти ожидания, и то что значительная часть этих ожиданий idle.
15 дек 15, 14:38    [18562913]     Ответить | Цитировать Сообщить модератору
 Re: как избавиться от virtual circuit wait  [new]
niv76
Member

Откуда: Киев
Сообщений: 115
wurdu
niv76
Администраторы говорят что проблем с шаред серверами и прочими диспатчерами нет.

Я бы так не сказал, т.к. в AWR мы видим 96.92% busy в Shared Servers Utilization.


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

Читал доку:

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_BUF
23181385277611218910143969707637121511691792
35148548521484512077918530331211761406
1100016064181990224818260216696
9914933522862142924790276371220159997
43075187142340319867326371280151923
0000133753919897808182101141321
3662271142673262199091526064151233629
1036364118454319934125303370201311
2538793263445873201792853010191204935
23000697287200857053010151101776
535807366643427202441143440812131426
49107733694607652294818270139413
2911141632182107720016235547718152878
9038377352155517443328182161162518



Прикреплю актуальные авр с обеих нод (время проблемного инсерта попало в АВР).

К сообщению приложен файл (awr_20151214_pro1.7z - 118Kb) cкачать
15 дек 15, 20:13    [18564932]     Ответить | Цитировать Сообщить модератору
 Re: как избавиться от virtual circuit wait  [new]
niv76
Member

Откуда: Киев
Сообщений: 115
Авр со второй ноды

К сообщению приложен файл (awr_20151214_pro2.7z - 122Kb) cкачать
15 дек 15, 20:14    [18564937]     Ответить | Цитировать Сообщить модератору
 Re: как избавиться от virtual circuit wait  [new]
niv76
Member

Откуда: Киев
Сообщений: 115
данные по системным вьюшкам в файлах (последняя цифра в имени файла = номеру запроса):

--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;

К сообщению приложен файл (queries.7z - 10Kb) cкачать
15 дек 15, 20:20    [18564954]     Ответить | Цитировать Сообщить модератору
 Re: как избавиться от virtual circuit wait  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
Я бы проверил в начале что это не Bug 11895446 - Excessive 'virtual circuit wait' with shared servers due to instance locks held in RAC environment (Doc ID 11895446.8).
Вообще конечно грустно все это выглядит. Два ядра, причем боюсь что виртуальные. CPU перегружены, ресурс менеджер душит шаред сервера. И еще зачем-то рак.
16 дек 15, 14:17    [18567823]     Ответить | Цитировать Сообщить модератору
 Re: как избавиться от virtual circuit wait  [new]
niv76
Member

Откуда: Киев
Сообщений: 115
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)


На выходных админы будут пробовать патчить сервер, посмотрим...
16 дек 15, 15:23    [18568337]     Ответить | Цитировать Сообщить модератору
 Re: как избавиться от virtual circuit wait  [new]
niv76
Member

Откуда: Киев
Сообщений: 115
пропатчили базу. Помогло. Кол-во вейтов осталось примерно то же. Но среднее время вейта упало на одной ноде примерно в 25 раз, на другой примерно в 50 раз.
Спасибо большое за помощь. :)
11 янв 16, 16:42    [18663316]     Ответить | Цитировать Сообщить модератору
Все форумы / Oracle Ответить