Re: High number of created consistent read blocks when inserting into a LOB column from dblink

Hey Jure,
beside the fact of the on-/off-cpu processes/events - you adjusted the sample rate to an average rate of only 99 samples/sec. Not quite sure how long you have sampled your process (based on the assumption that it would be fully on CPU: 7 to 8 secs), but the whole captured data includes only 722 and 828 samples.

I think you are looking for something different as you want to get the difference in the Oracle C kernel function flow - you should use SystemTap instead. It might be a little bit more "complicated" to get it running (especially if you need to build your own kernel debug info package first), but then you can follow the Oracle C kernel as you need it in this case :-)

P.S.: For isolating the issue it might be easier to insert only one row and check the difference.

Best Regards
Stefan Koehler

Independent Oracle performance consultant and researcher Homepage: http://www.soocs.de
Twitter: _at_OracleSK  

> Jure Bratina <jure.bratina_at_gmail.com> hat am 12. Januar 2017 um 21:02 geschrieben:
>
> Hi Stefan,
>
> > How did you capture the stack traces - with perf?
> Yes:
> perf record -F 99 -p <pid of target process> -g -- sleep 60
> perf script | ./http://stackcollapse-perf.pl > out.perf-folded
> ./http://flamegraph.pl out.perf-folded > perf-kernel.svg
> I'm not sure whether I can send attachments to the list, so if it's of any interest, here
> https://www.dropbox.com/sh/ba4seqzw7wo7y8q/AADoCPF8zAQT89rDayXZqh6ba?dl=0&lst=
> https://www.dropbox.com/sh/ba4seqzw7wo7y8q/AADoCPF8zAQT89rDayXZqh6ba?dl=0&lst= are two flame graphs captured on the problematic database. It's true
> that they were not captured when the process was 90%+ on CPU (if I remember correctly, CPU usage was around 40-50% when the samples were made), but
> since the issue originally manifested as the process being mostly on CPU, I thought to sample just that. But, based on what you wrote, they might
> not be as useful as I thought :-)
>
> > However you also can sample off-CPU processes/events with perf: http://www.brendangregg.com/blog/2015-02-26/linux-perf-off-cpu-flame-graph.html
> > http://www.brendangregg.com/blog/2015-02-26/linux-perf-off-cpu-flame-graph.html
> Thanks for the link, I'll try to run the test again on the problematic database and see what emerges.
>
> Thank you and regards,
> Jure Bratina

--
http://www.freelists.org/webpage/oracle-l