Hi Stefan,
Now it makes sense, thanks for the explanation. If I find out anything
useful/interesting I'll post it.
Regards,
Jure Bratina
On Fri, Jan 13, 2017 at 9:59 AM, Stefan Koehler <contact@xxxxxxxx> wrote:
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:45geschrieben:
row and check the difference.
Thanks for the feedback Stefan.
One question though:
> P.S.: For isolating the issue it might be easier to insert only one
The problem is that the issue of the INSERT slowing down and becomingmore and more CPU intensive manifests gradually. At the beginning, things
run
smoothly, CPU usage is low, the deltas of "CR blocks created" arerelatively 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 beheavily 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
