[OpenIndiana-discuss] ZIL write cache performance

wessels wessels147 at gmail.com
Sat Jan 14 22:20:23 UTC 2012


Hi Matt,

As Steve pointed out there's a performance regression since oi148
(including oi151a upto today) when using a SLOG as ZIL. As submitter
of the bug, https://www.illumos.org/issues/1909 , I advise you to test
with a SLOG on oi148 as well. This is the best performance you can
expect, apart from disabling the ZIL. At the moment the patch set of
George only brings back performance upto 80% of oi148. The fix isn't
in illumos yet, you must apply the patch manually. We're working on
getting the remainder back as well.
Please use zilstat to verify usage of the ZIL and obtain some
datapoints. And remember that very few SSD's are happy being an SLOG,
they wear out,performance can drop under load and some may lose data
in case of sudden powerloss. Most dram based device don't have these
problems, and have much shorter latencies then SSD.

On Fri, Jan 13, 2012 at 12:34 AM, Steve Gonczi <gonczi at comcast.net> wrote:
> Hi Matt,
>
> The ZIL is not a performance enhancer. (This is a common misunderstanding,
> people sometimes view the ZIL as a write cache) .
>
> It is a way to simulate "sync" semantics on files where you really
> need that, instead of the coarser ganularity guarantee that zfs gives
> you without it. (txg level, where the in-progress transaction group may
> roll back if you crash).
>
> If I am reading your post correctly, you are comparing 2 scenarios
>
> 1) Zil is enabled, and goes to the main storage pool
> 2) Zil is enabled but it goes to a dedicated SSD instead.
> Please verify that this is indeed the case.
>
> You should not expect having an SSD based zil performing better than
> when turning the ZIL off altogether.
>
> The latter of course will have better
> performance, but you have to live with the possibility of losing some data.
>
> Given that the case is (1) and (2), it all depends on how much performance
> headroom your pool has, vs. the write performance of the SSD.
>
> A fast SSD ( e.g.: DRAM based, and preferably dedicated to Zil and not split)
> would work best. It does not have to be huge, just large enough to store (say)
> 5 seconds worth of your planned peak data inflow.
>
> You need to be aware of a recent performance regression discovered pertaining to
> ZIL ( George Wilson has just posted the fix for review on the illumos dev list)
> This has been in Illumos for a while, so it is possible, that it is biting you.
>
> Steve
>
> ----- Original Message -----
> Hi, I've installed an SSD drive in my OI machine and have it partitioned (sliced) with a main slice to boot from and a smaller slice to use as a write cache (ZIL) for our data pool.
>
> I've noticed that for many tasks, using the ZIL actually slows many tasks at hand (operation within a qemu-kvm virtual machine, mysql loading importing a dump file, etc). I know I bought a cheap SSD to play with so I wasn't expected the best performance, but I would have expected some improvement, not a slow down.
>
> In one particular test, I have mysql running in a zone and loading a test data set takes about 40 seconds without the ZIL and about 60 seconds with ZIL. I certainly wasn't expecting a 50% slow down.
>
> Is this to be expected?
>
> Are there any best practices for testing an SSD to see if it will actually improve performance of a zfs pool?
>
>
> Thanks,
> Matt
>
>
> _______________________________________________
> OpenIndiana-discuss mailing list
> OpenIndiana-discuss at openindiana.org
> http://openindiana.org/mailman/listinfo/openindiana-discuss
> _______________________________________________
> OpenIndiana-discuss mailing list
> OpenIndiana-discuss at openindiana.org
> http://openindiana.org/mailman/listinfo/openindiana-discuss



More information about the OpenIndiana-discuss mailing list