3 ms·

I know what you're getting at, I wondered the same thing, but my results were the opposite of what I expected for compression. I enabled lz4 compression and se

by tomxor 3y ago

I know what you're getting at, I wondered the same thing, but my results were the opposite of what I expected for compression. I enabled lz4 compression and set recordsize for database datasets to 16k to match innoDB... turns out even at 16k my databases are extremely compressible 3-4x AFAIR (I didn't write the DB schema for the really big DBs, they are not great, and I suspect that there is a lot of redundant data even within 16k of contiguous data)... maybe I could get even more throughput with larger record sizes, but seems unlikely. As you say, mileage will vary, it's subjective, but then I wasn't using compression before ZFS, so I don't have a comparison. I have only done basic performance testing, overall it's an improvement over ext4, but I've not been trying to fine tune it, I'm just happy to not have made it worse so far while gaining ZFS.

yjftsjthsd-h 3y ago
Oh, nice. In my case I sort of forgot to set the record sizes, got great compression, and then realized I'd missed the record sizes so tried lowering/matching them and watched compression ratio drop to... I think all the way to 1.0:( So that was a natural experiment, as it were. But of course it totally depends on the exact size and most of all your data.
- tomxor 3y ago
  I suppose ultimately the thing to test is application performance, (assuming you don't care too much about disk space). Because it depends on the access pattern. If reading and writing contiguously, then large record sizes (even if unaligned) with high compression ratio might be fastest. but if it's more weighted to highly randomised, then the larger ZFS record sizes might actually cause read and write amplification and a lower throughput even if the overall on-disk size is smaller (assuming it doesn't all fit in memory in which case this is all moot). Another new thing that's possible with innoDB these days is that you can actually change the default 16k page size, i.e you could align innoDB to your preferred ZFS recordsize if that makes sense for your application.

by tomxor 3y ago

yjftsjthsd-h 3y ago

Oh, nice. In my case I sort of forgot to set the record sizes, got great compression, and then realized I'd missed the record sizes so tried lowering/matching them and watched compression ratio drop to... I think all the way to 1.0:( So that was a natural experiment, as it were. But of course it totally depends on the exact size and most of all your data.

tomxor 3y ago
I suppose ultimately the thing to test is application performance, (assuming you don't care too much about disk space). Because it depends on the access pattern. If reading and writing contiguously, then large record sizes (even if unaligned) with high compression ratio might be fastest. but if it's more weighted to highly randomised, then the larger ZFS record sizes might actually cause read and write amplification and a lower throughput even if the overall on-disk size is smaller (assuming it doesn't all fit in memory in which case this is all moot). Another new thing that's possible with innoDB these days is that you can actually change the default 16k page size, i.e you could align innoDB to your preferred ZFS recordsize if that makes sense for your application.