ZFS compression: perf, disk-space, and watts. The naked truth. (part 2 of 2)

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 a 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.

Comments:

Post a Comment:
Comments are closed for this entry.
About

Application tuning, sizing, monitoring, porting on Solaris 11

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
5
6
8
9
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today