Is LZ4 compression of the ZFS L2ARC available in any RELEASE/STABLE?

[Karl Denninger]

It probably won't matter all that much.

You need to profile this but you can get a decent idea what's going on
from sysstat or iostat; look at the transaction count, size per
transaction and percentage of time the disks are busy.  I bet you find
low transaction size, moderate count and very high disk busy
percentages, which points to lots of head movement on an average basis
compared against bytes moved.

That's the paradigm where spinning rust loses, basically, and the only
answers are to spread the I/O across more spindles so you get more
positioner economy, go to faster-rotating drives with faster seek times
or move to SSDs.

If your I/O pattern is as I suspect the first thing to do is get the
L2ARC off the rest of the pool's disks as that de-couples that I/O from
the actual data storage.  In mixed, small I/O environments this
frequently will double total throughput and it costs you just one
spindle, and it can be a small one too as the L2ARC requirement is
modest.  Making that L2ARC a SSD is an option but beware of using cheap
ones there as fault-tolerance rules apply to L2ARC as they do to data
disks (this is not true for a cache drive which is ignored if it posts
errors and results in no data loss.)

Presuming that doesn't provide enough boost the next logical move is to
consider putting the DBMS on SSDs itself.  That completely removes
positioning latency and will result in a massive speed increase.

On 3/5/2014 1:17 AM, Olav Gjerde wrote:
> Currently I've set the recordsize to 8k, however I'm thinking maybe a
> recordsize of 4k may more optimal?
> This is because the compressratio with LZ4 is around 2.5 and this value has
> been constant for all my data while growing from a few megabytes to a
> tenfold of gigabytes.
> Maybe something I should play with to see if it makes a difference.
>
>
> On Wed, Mar 5, 2014 at 3:40 AM, Bob Friesenhahn <
> bfriesen at simple.dallas.tx.us> wrote:
>
>> On Tue, 4 Mar 2014, Olav Gjerde wrote:
>>
>>  I managed to mess up who I replied to and Matthew replied back with a good
>>> answer which I think didn't reach the mailing list.
>>>
>>> I actually have a problem with query performance in one of my databases
>>> related to running PostgreSQL on ZFS. Which is why I'm so interested in
>>> compression for the L2ARC Cache. The problem is random IO read were
>>> creating a report were I aggregate 75000 rows takes 30 minutes!!! The
>>> table
>>> that I query has 400 million rows though.
>>> The dataset easily fit in memory, so if I run the same query again it
>>> takes
>>> less than a second.
>>>
>> Make sure that your database is on a filesystem with zfs block-size
>> matching the database block-size (rather than 128K).  Otherwise far more
>> data may be read than needed, and likewise, writes may result in writing
>> far more data than needed.
>>
>> Regardless, L2ARC on SSD is a very good idea for this case.
>>
>> Bob
>> --
>> Bob Friesenhahn
>> bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
>> GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
>>
>
>

-- 
-- Karl
karl at denninger.net


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2711 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20140305/3651b09a/attachment.bin>