|
When running 12.0.1.3298 on an Intel Core i7 Q720 with Task Manager showing 8 CPUs, it is possible to run a CPU-intensive query that starts 8 separate "INT: Exchange" connections that report enormous CONNECTION_PROPERTY ( 'ApproximateCPUTime' ) values while the originating client connection reports zero: SELECT COUNT(*)
FROM SYSCOLUMN AS A
CROSS JOIN SYSCOLUMN AS B
CROSS JOIN SYSCOLUMN AS C;
On a busy server, how do I identify the culprit? I.e., how do I trace the "INT: Exchange" connections back to the originating client connection? ...and are there any other "INT: ..." connections that behave similarly? |
|
FWIW, doing validation with v12.0.1.3554 shows a similar behaviour, i.e. running several short-living internal "INT: Exchange" connections with increasing "ApproximateCPUTime" whereas the triggering connection does not increment that value. However, as soon as the internal connections are dropped, then their CPU times seems to get summed up for the parent connection. - During validation, this happens multiple times, as there are multiple cycles of creating, running and dropping internal "Exchange" connections. Checked on a different connection via: select connection_property('ApproximateCPUTime', sci.Number), * from sa_conn_info() sci AFAIK it's intra-query parallelism. Have you noticed that the individual numbers for INT:Exchange ApproximateCPUTime are much larger than they should be; e.g., if there are 8 of them, each number is 8 times what it should be?
(19 Mar '12, 08:06)
Breck Carter
Replies hidden
Sorry, no, I haven't checked nor stored the numbers - and was just using a box with 2 CPUs, so the effect would not have been that obvious...
(19 Mar '12, 08:39)
Volker Barth
|
