Hey Jure,
sorry, i did not get your point with flame-graph. How did you capture the stack
traces - with perf?
If yes, perf only samples on-CPU processes/events by default which means that
you captured nothing and the other stuff might be irrelevant when your
process wasn't mostly on CPU. 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
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 17:55
geschrieben:
Regarding the problematic database, I made a quick flamegraph analysis on it
when wasn't mostly on CPU, and a large portion of the time was spent
in functions which seem to manage LOB space, e.g. kdliAllocChunks,
ktsl_fill_dispenser_main, ktsla_ins_chunk, so like it was mentioned, it seems
that the problem lies in the LOB space management, however the root cause of
the slowdown on the problematic database is (still) unknown.
Regards,
Jure Bratina
