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

[Karl Denninger]

There's all sorts of issues here and as someone who uses Postgres on
ZFS/FreeBSD in a heavy mixed-I/O environment I'm pretty aware of them.

Getting the L2ARC cache OFF the spindles where the data set is will make
a huge difference in performance in any mixed I/O (read and write)
environment.  The interleaving of that data on the base data set is
murder on spinning rust due to the requirement to move the heads.

I strongly recommend starting there.

UFS *may* be faster, but don't count on it as the small I/O issue still
is a serious factor and seek times becomes the overwhelming latency
problem very quickly with small I/Os.  Remember too that you still need
data protection (e.g. RAID, Gmirror, etc.)  Benchmark for your workload
and see.

If that's not enough going to SSDs erases the head-movement penalty
completely.  You may well see improvements in net I/O under mixed
database loads as high as 20 or more *times* (not percent) what you get
from rotating media for this reason, especially with the better SSD
devices.  I have clocked (under synthetic conditions) improvements in
I/O latency on "first accesses" for data not in-RAMcache as high as *one
hundred times* if the workload includes interleaved writes (e.g. large
numbers of clients who both need to read and write at once.)

On 3/4/2014 2:33 PM, 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.
>
> I'm going to test UFS with my dataset, it may be a lot faster as you said.
> Currently I've only tested ZFS with gzip, lz4 and no compression. Gzip and
> no compression has about the same performance and LZ4 is about 20%
> faster(for both read and write). LZ4 has a compressratio about 2.5 and
> gzip9 has a compressratio that is about 4.5
>
> Steven Hartland, thank you for your suggestion. I will try the 10-STABLE
> then instead of a RELEASE.
>
>
> On Tue, Mar 4, 2014 at 2:25 PM, Matthew Seaman <matthew at freebsd.org> wrote:
>
>> On 03/04/14 12:17, Olav Gjerde wrote:
>>> This is really great, I wonder how well it plays together with PostgreSQL
>>> and a SSD.
>> You probably *don't* want to turn on any sort of compression for a
>> Postgresql cluster's data area (ie. /usr/local/pgsql) -- and there are a
>> bunch of other tuning things to make ZFS and Pg play well together, like
>> adjusting the ZFS block size.  The sort of small random IOs that RDBMSes
>> do are hard work for any filesystem, but particularly difficult for ZFS
>> due to the copy-on-write semantics it uses.  It's a lot easier to get
>> good performance on a UFS partition.
>>
>> On the other hand, ZFS has recently grown TRIM support, which makes it a
>> much happier prospect on SSDs.
>>
>>         Cheers,
>>
>>         Matthew
>>
>>
>>
>>
>

-- 
-- 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/20140304/df986a2e/attachment.bin>