That is an interesting thought. I did check the aggregate CPU utilization (Dual 6-core 2.0GHz Xeon, E5-2630L) and overall it looks fine with a load average below 0.5 during transfers. However, I have not checked if there is a single thread that is blocking the process. I guess the cheap way to verify your assumption is to run the process on a faster processor. If the throughput goes up with the speed of the CPU that would indicate we're on the right track. I think we have a couple of E-2637v2's laying around, let me see if I can get those swapped in.
W > On December 9, 2013 at 3:15 PM Jim Klimov <[email protected]> wrote: > > > Reading your description, I thought "can it be a single-CPU > performance issue?" Perhaps, decompressing your datasets > (or compressing upon write - though the /dev/null experiment > rules that out), or building the stream, or any other step > in your data path, might for some reason be a single-threaded > task. Running several in parallel splits them across many > cores, but one is slow. > > Not being a ZFS developer, I am not ready to check and point > the place in code where that guess might be (dis-)proved, > but at least I'd start digging (and asking) with such an > assumption :) > > At least, there are many things in parallel IT processing > that are made fast by sheer scale of concurrent independent > tasks, rather than (expensively) trying to parallelize the > code inside. And on average the cheap approach pays off ;) > > //Jim > > > _______________________________________________ > OpenIndiana-discuss mailing list > [email protected] > http://openindiana.org/mailman/listinfo/openindiana-discuss _______________________________________________ OpenIndiana-discuss mailing list [email protected] http://openindiana.org/mailman/listinfo/openindiana-discuss
