Hey Jure,
at first you need to know how a fast C stack looks like (usually from opiodr()
in your case) - this is why i suggested to insert only one row and
capture this execution with SystemTap. Afterwards you can run your huge INSERT
and wait until it burns up CPU - then you capture one row processing
out of that huge INSERT with SystemTap and compare. Does this make sense to you?
I am pretty sure that you may see several CR C function calls from one base C
function - this would be the reason for your "CR blocks created" then.
If you have the base C function, you can check for a specific tracing event of
this (in Oracle code). You can get all of this from the Oracle C kernel
code, but i am not allowed to post an instruction about this here (due to
official Oracle licensing terms and conditions).
Best Regards
Stefan Koehler
Independent Oracle performance consultant and researcher
Homepage: http://www.soocs.de
Twitter: @OracleSK
Jure Bratina <jure.bratina@xxxxxxxxx> hat am 12. Januar 2017 um 23:45
geschrieben:
Thanks for the feedback Stefan.
One question though:
> P.S.: For isolating the issue it might be easier to insert only one row
and check the difference.
The problem is that the issue of the INSERT slowing down and becoming more
and more CPU intensive manifests gradually. At the beginning, things run
smoothly, CPU usage is low, the deltas of "CR blocks created" are relatively
low. As the INSERT progresses, CPU usage rises, as do deltas for "CR
blocks created" among other statistics. I might be missing the point, but if
I try to insert a single row and observe the difference, I'll do that
at the beginning of the transaction, i.e. when the process won't be heavily
on CPU, so I wonder if I'll see why the process is so heavily on CPU and
building consistent read images of blocks?
Regards,
Jure Bratina
