Optimizing performance with SLOG/L2ARC

PK1048 paul at pk1048.com
Wed Aug 19 16:06:13 UTC 2015


On Aug 19, 2015, at 11:46, kpneal at pobox.com wrote:

> On Wed, Aug 19, 2015 at 11:29:44AM -0400, PK1048 wrote:
>> Someone commented on the size of the ZIL/SLOG… it needs to hold all of the write data that arrives between TXG commits, which happen at least every 5 seconds (it used to be 30 seconds, but that scared too many people :-). SU a sync write arrives and it _must_ be committed to permanent storage, so ZFS writes it to the ZFS Intent Log (ZIL) which may or may not be a separate device (vdev). When the TXG that contains that data is committed to the pool itself the data can be flushed from the ZIL. If your source of sync writes is network shares, and you have a 1 Gbps link, then your maximum ZIL will be 5 seconds x 1 Gbps or 5 Gigabits.
> 
> That was me. By your figures 5 Gigabits is small compared to the size of
> SSD these days. If the SLOG ends up being that important to performance
> then it may make sense to buy small, excellent quality SSD.

Exactly, unless your sync write data is coming from a _local_ application or you have multiple 10 G ethernet connections :-)

When I asked about SSD recommendations and sizing over on the OpenZFS list, the consensus was that a 32 GB log device was probably big enough for any rational load. I ordered 200 GB 3710’s … sometimes performance also scales with capacity, so be careful buying the smallest SSD that fits the strict size needs. I will partition them and use some for LOG and some for L2ARC (if I need it). I know this is not recommended, but if it works, why not (and I do understand the limitations of such a configuration). I only have 24 GB RAM in this box and can probably benefit from some L2ARC.

> I believe they even make PCIe battery-backed up RAM for this use. I have
> no idea about the price, though. Probably a lot. But maybe "a lot" isn't
> much depending on the value of the service provided by the machine.

I have seen the RAM based battery-backed-up drives, and some are not even ludicrous in terms of price, but I did not see any with FreeBSD driver support. Since they are generally PCIe based (for speed), drives are needed.



More information about the freebsd-fs mailing list