You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Mar 17, 2025. It is now read-only.
Thank you for sharing the details of your setup and the thoughts behind it.
I'm wondering a little how big, in your case, the benefits of using the compression are.
From #2 I understood it actually saves space only if a 16KB block is compressed to 8KB or less, while the CPU cycles are burnt in any case. So the effect of the compression is kind of just binary and it can't get better than 50%.
On the other hand, the InnoDB reads & writes (actually happening on an mmap()-ed file) would be much more straightforward for the filesystem & the kernel if the ZFS compression were not used.
A couple of questions if you allow:
What is the compression ratio you are actually experiencing?
Based on the demand surge you are expecting in the future, when would you be out of storage space (a) with your current setup, and (b) without using the ZFS compression?
Could you possibly estimate the effect of the compression being on/off on your server's CPU utilisation and on its energy consumption?
Should compression be justifiable, wouldn't it be more efficient to partition the big transaction table(s) into a live partition and a series of read-only, archival ones, with a more aggresive compression applied on the latter?