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

  • From: Stefan Koehler <contact@xxxxxxxx>
  • To: jure.bratina@xxxxxxxxx
  • Date: Thu, 12 Jan 2017 21:49:55 +0100 (CET)

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: @OracleSK
 

Jure Bratina <jure.bratina@xxxxxxxxx> 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
--
//www.freelists.org/webpage/oracle-l


Other related posts: