Here is the follow-up on the first ZFS compression article where I've been discussing the performance gain that compression brings and the way to measure power consumption with OpenSolaris.
With a simple benchmark consisting in copying/duplicating a 4.8GBytes file, I checked that ZFS compression improves the IO perf. I now want to measure the impact on power consumption.
During the 7m19sec that it takes to cp the large file without compression, my computer consumes 3.65Wh for an average power of 29.9W. During the 5.26sec with compression=on it consumes 2.88Wh for an average power of 31.82W.
To focus even more on the energy specifically consumed by the IOs I can substract the energy that my laptop consumes when idle, i.e. 22W (see previous article for details). This turns in 2.68Wh for 7m19sec and 1.99Wh for 5.26sec. I end up with the following numbers:
- 0.97Wh for IOs without compression
- 0.89Wh for IOS with compression=on
Turning compression on consumes more power but thanks to the extra speed it saves energy with a 1.09x factor - 9%.
On my laptop, compression has a triple positive impact:
- Improves IO performance by a factor of 1.35x
- Saves space by of factor of 1.77x
- Saves energy during IOs by of factor of 1.09x
To close this article, let's have a look at the different compression algorithms available with ZFS. For my experiment, I have been using the default by setting compression=on on the ZFS file-system. The man pages tell me that by default ZFS uses the lzjb algorithm "that is optimized for performance while providing decent data compression". Yet, the gzip algorithm is avaiable too, and I can specify the gzip level by using the value "gzip-N where N is an interget from 1 (fastest) to 9 (best compression ratio). Currently, gzip is equilvalent to gzip-6". Let's do a quick test.
First, I delete the data in the file-system where I want to do the test, then I set compression=gzip-1 on it:
# rm /rpool/compressFS/*
# zfs set compresssion=gzip-1 /rpool/compressFS/*
Then, I create a large file - mine is 4.8GBytes - to this file-system and I cp the large file into the same file-system:
# time cp OpenSolaris2009.06.vdi foo.vdi
real 5m4.266s
user 0m0.095s
sys 0m5.903s
# zfs get compressratio rpool/compressFS
NAME PROPERTY VALUE SOURCE
rpool/compressFS compressratio 2.57x -
5m42sec for the real-time and 2.57x for the compression ratio. With compression=gzip-9 I get 12m32sec for real-time and 2.82x for the compression ratio.
These values have to be compared with the ones for compression=on (see previous article for the details): 5m26sec for real-time and 1.77x for the compression ratio.
With my laptop, the default compression provides me the best performance, while gzip-1 brings me a much better compression ratio with a minimal impact on perf. Gzip-9 slightly improves the ratio over gzip-1 but with a very negative impact on perf. For sure the differences between these algorithms depend on the disk's speed and on the data being compressed. If I were using and SSD instead of a hard-disk, algorithms with a low compression ratio - hence the onces where CPU is waiting for the disk - would probably see a boost in performance.
Umm... did you take into account that the file may have been cached (for reads) in the 2nd and on copy tests?
Posted by Yaniv on November 09, 2009 at 12:10 PM CET #
Hi Yaniv, valid question.
I just reran the cp with compression on and off just after rebooting my laptop to make sure the cache was empty in both cases.
BTW, in both cases, before the cp the ARC size was around 400MB. Just after the cp the ARC size was 1040MB with compression=on and 1188MB without compression. The cp used the cache in both cases.
Bottom line after reboot:
- With compression=on 5m21sec - versus 5m26sec during my previous tests. The empty cache did not bring any negative impact.
- Without compression the 7m28sec - versus 7m20sec during my previous tests. The empty cache seems to bring a negative impact but the variation is under 2% so it does not mean much.
Regards,
Thierry
Posted by Thierry on November 09, 2009 at 07:44 PM CET #