ZFS dedup write pathway - possible inefficiency or..?

[Andriy Gapon]

On 02/04/2018 21:30, Stilez Stilezy wrote:
> Thanks on that tip, Andriy,
> 
> I don't have the knowledge to tell if that's the first of the 2 issues I'm
> seeing.  It could be. What exactly is that bug describing and what behaviour
> would it create?

Sub-optimal performance for ZFS write throughput (and latency) when dedup is
enabled and you are trying to write as fast as you can.

> Assuming it's the same -
> 
> 1) Are there any known workarounds or sysctls that help to reduce the issue?

I don't know of any.

> 2) Are there any easy diagnostic tests I can easily do, to confirm if this is
> the same behaviour as that bug?  Nobody else uses the test system, so I can
> change any sysctls to sane or extreme values for testing, or create large txg's
> and spread out reads and writes to see what's happening and what coincides with
> what.

We used DTrace to observe internal ZFS behavior.
I do not have any simple recipes.

> On 2 April 2018 at 18:47, Andriy Gapon <avg at freebsd.org
> <mailto:avg at freebsd.org>> wrote:
> 
>     On 02/04/2018 16:36, Stilez Stilezy wrote:
>     > The first issue is specific to the
>     > dedup write pathway.   I've tested locally to a point where it seems it's
>     > not due to inadequate hardware and it's very consistent and specific, even
>     > on idle conditions/minimal load.  I'm wondering whether there's a code
>     > bottleneck specifically affecting just the dedup write pathway.
> 
>     I think that this might be https://www.illumos.org/issues/8353
>     <https://www.illumos.org/issues/8353>
> 
>     --
>     Andriy Gapon
> 
> 


-- 
Andriy Gapon