On 2/17/2016 6:07 PM, Dan Langille wrote:
On Feb 17, 2016, at 9:57 AM, Martin Simmons <mar...@lispworks.com
<mailto:mar...@lispworks.com>> wrote:
On Tue, 16 Feb 2016 18:59:10 -0500, Dan Langille said:
As a test, I scp'd over all the volumes for one job and timed it:
real 167m15.956s
user 117m51.006s
sys 23m56.653s
FWIW, these copies were done while a ZFS scrub was underway, so if
anything, the potential throughput is higher.
The job above, took nearly 11 hours. Something is up.
I tried another test run, just now, but cancelled it after the first
two Volumes were read; it was going at about the same rate as the
full job mentioned above.
What might account for this vast difference?
You could try profiling it, e.g
http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html#DTrace
This is a great idea. Have you done this before? I haven't and my
first attempt seems to be interesting.
http://www.langille.org/tmp/bacula-copy.svg
It didn't run very long, and thus I'm not sure how relevant the
information is
Interesting, Dan. I wonder what it looks like for that same job with
encryption turned off. If I am reading the graph correctly, it looks
like AES encryption is more than doubling the CPU usage.
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
