Now, logfiles tend to be compressible, so in preparation for migrating it to a new host (it's a zone, so moving from one physical host to another is trivial) I tested ZFS compression to see how well that would work.
| Type | Ratio |
|---|---|
| lzjb | 5.08x |
| gzip | 22.19x |
| gzip-1 | 16.37x |
Now, the default lzjb gives you fair compression. That saves 80% of my storage, so that's pretty good.
Going to gzip compression the space saving is spectacular. Unfortunately the machine runs like it's stuck in treacle, so that's not exactly practical.
Which is why I tried gzip-1. You save much more space than lzjb, although not as much as the default gzip (which is gzip-6). Unfortunately, while the machine doesn't quite go as comatose as it does with the regular gzip compression, the performance impact is still noticeable.
Overall, while I wouldn't mind the extra compression, the performance impact makes it hard, so I'm going to stick with the regular lzjb.
8 comments:
WHAT KIND OF CPU DOES IT HAVE? WHAT'S THE AVERAGE CPU UTILIZATION WITHOUT COMPRESSION, AND WITH EACH OF 3 TYPES? 1GB/DAY IS NOT A LOT OF I/O; IS THERE ANY OTHER SIGNIFICANT I/O GOING ON? THANKS.
It's an X2200M2- twin dual-core opteron. Cpu utilization on lzjb is negligible; about 50% for gzip-1 and 80% for gzip. That's not the problem, the fact that it goes almost unresponsive for seconds at a time isn't acceptable.
How was the test done? Did you enable compression on a file system that has this log file "active" (meaning, it is still actively logging things to that file)?
Or did you create a file system with the different compression settings and then copy the log file to that directory?
It's a very practical feature. I do the same thing (gzip -9) with a big bunch of mails (stored in plaintext). The result is a compressratio of 1.86x.
Hmm, did you try creating a zfs volume just for the log files, and enabling compression only on that? It should give you the benefits of the extra compression, without slowing down all of the system.
The tests were simply creating a new zfs filesystem and copying the old system to it.
It's almost all logfiles; there's no point trying to split out the rest.
The whole aim of using compression in the filesystem is so that it's transparent to the user. Handing over a new server that randomly freezes for seconds at a time while actually doing anything isn't likely to be considered either much of an upgrade or terribly friendly.
And the normal lzjb compression gets rid of over 80% of the space usage, which is basically good enough.
gzip is definitely a step up, space-saving-wise, from the default lzjb, but as you say, it makes the system very laggy. While testing it here, writing 10GB of real-life data to my pool (Quad-core Q9400 @2.66 GHz), it was hard to use an SSH shell as the system made letters stumble about, and sometimes keystrokes were lost. Which is interesting, because it wasn't the CPU that was taxed mostly - I think it's a combination of CPU taxation and interrupt hell.
Either way, for a file server only (with few users or little contiguous data being written), it can be attractive. My 10GB became 4GB with lzjb, 3.3GB with gzip-9. Speeds were 109 MB/s write, 636 MB/s read with lzjb, 41 and 611 MB/s with gzip-9.
So a definite punishment in writes with gzip-9, not so much with reads. And given that it's extremely rare that I'd write a large file like that full-throttle, the slow write speeds are acceptable to me. Also, this would be via Gbit ethernet, so I'm maxing out anyway at somewhere between 70 and 80 MB/s read AND write.
Forgot to say: Those insane (to me) read speeds are actually *because* of enabling compression.
The fastest I've seen with "regular", uncompressed, reads on my pool thus far (without having done extensive testing), is 360 MB/s.
Again, matters little for this purpose as the bottleneck is the ethernet tether, but it's still interesting :)
Post a Comment