>Do you mean that it would be faster to read compressed data than uncompressed 
>data, or it would be faster to read compressed data than to write it?

yes, because read needs more less CPU time, and the I/O is the same with write.

Do you test it in other environment? likely, increase the server memory?  or 
increase the clients?



________________________________
From: David Pacheco <david.pach...@sun.com>
To: Chookiex <hexcoo...@yahoo.com>
Cc: zfs-discuss@opensolaris.org
Sent: Friday, June 26, 2009 1:00:36 AM
Subject: Re: [zfs-discuss] Is the PROPERTY compression will increase the ZFS 
I/O throughput?

Chookiex wrote:
> thank you ;)
> I mean that it would be faster in reading compressed data IF the write with 
> compression is faster than non-compressed? Just like lzjb.


Do you mean that it would be faster to read compressed data than uncompressed 
data, or it would be faster to read compressed data than to write it?


> But i can't understand why the read performance is generally unaffected by 
> compression? Because the uncompression (lzjb, gzip)  is faster than 
> compression in algorithm, so I think reading the compressing data would need 
> more less CPU time.
> 
> So the conclusion in the blog that "read performance is generally unaffected 
> by compression", I'm not agreed with it.
> Except the ARC cached the data in the read test and there are no random read 
> test?


My comment was just an empirical observation: in my experiments, read time was 
basically unaffected. I don't believe this was a result of ARC caching because 
I constructed the experiments to avoid that altogether by using working sets 
larger than the ARC and streaming through the data.

In my case the system's read bandwidth wasn't a performance limiter. We know 
this because the write bandwidth was much higher (see the graphs), and we were 
writing twice as much data as we were reading (because we were mirroring). So 
even if compression was decreasing the amount of I/O that was done on the read 
side, other factors (possibly the number of clients) limited the bandwidth we 
could achieve before we got to a point where compression would have made any 
difference.

-- Dave


> My data is text data set, about 320,000 text files or emails. The compression 
> ratio is:
> lzjb 1.55x
> gzip-1 2.54x
> gzip-2 2.58x
> gzip 2.72x
> gzip-9 2.73x
> 
> for your curiosity :)
> 
> 
> ------------------------------------------------------------------------
> *From:* David Pacheco <david.pach...@sun.com>
> *To:* Chookiex <hexcoo...@yahoo.com>
> *Cc:* zfs-discuss@opensolaris.org
> *Sent:* Thursday, June 25, 2009 2:00:49 AM
> *Subject:* Re: [zfs-discuss] Is the PROPERTY compression will increase the 
> ZFS I/O throughput?
> 
> Chookiex wrote:
>  > Thank you for your reply.
>  > I had read the blog. The most interesting thing is WHY is there no 
>performance improve when it set any compression?
> 
> There are many potential reasons, so I'd first try to identify what your 
> current bandwidth limiter is. If you're running out of CPU on your current 
> workload, for example, adding compression is not going to help performance. 
> If this is over a network, you could be saturating the link. Or you might not 
> have enough threads to drive the system to bandwidth.
> 
> Compression will only help performance if you've got plenty of CPU and other 
> resources but you're out of disk bandwidth. But even if that's the case, it's 
> possible that compression doesn't save enough space that you actually 
> decrease the number of disk I/Os that need to be done.
> 
>  > The compressed read I/O is less than uncompressed data,  and decompress is 
>faster than compress.
> 
> Out of curiosity, what's the compression ratio?
> 
> -- Dave
> 
>  > so if lzjb write is better than non-compressed, the lzjb read would be 
>better than write?
>  >  Is the ARC or L2ARC do any tricks?
>  >  Thanks
>  >
>  > ------------------------------------------------------------------------
>  > *From:* David Pacheco <david.pach...@sun.com 
><mailto:david.pach...@sun.com>>
>  > *To:* Chookiex <hexcoo...@yahoo.com <mailto:hexcoo...@yahoo.com>>
>  > *Cc:* zfs-discuss@opensolaris.org <mailto:zfs-discuss@opensolaris.org>
>  > *Sent:* Wednesday, June 24, 2009 4:53:37 AM
>  > *Subject:* Re: [zfs-discuss] Is the PROPERTY compression will increase the 
>ZFS I/O throughput?
>  >
>  > Chookiex wrote:
>  >  > Hi all.
>  >  >
>  >  > Because the property compression could decrease the file size, and the 
>file IO will be decreased also.
>  >  > So, would it increase the ZFS I/O throughput with compression?
>  >  >
>  >  > for example:
>  >  > I turn on gzip-9,on a server with 2*4core Xeon, 8GB RAM.
>  >  > It could compress my files with compressratio 2.5x+. could it be?
>  >  > or I turn on lzjb, about 1.5x with the same files.
>  >
>  > It's possible, but it depends on a lot of factors, including what your 
>bottleneck is to begin with, how compressible your data is, and how hard you 
>want the system to work compressing it. With gzip-9, I'd be shocked if you saw 
>bandwidth improved. It seems more common with lzjb:
>  >
>  > http://blogs.sun.com/dap/entry/zfs_compression
>  >
>  > (skip down to the results)
>  >
>  > -- Dave
>  >
>  >  >
>  >  > could it be? Is there anyone have a idea?
>  >  >
>  >  > thanks
>  >  >
>  >  > ------------------------------------------------------------------------
>  >  >
>  >  > _______________________________________________
>  >  > zfs-discuss mailing list
>  >  > zfs-discuss@opensolaris.org <mailto:zfs-discuss@opensolaris.org> 
><mailto:zfs-discuss@opensolaris.org <mailto:zfs-discuss@opensolaris.org>>
>  >  > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
>  >
>  >
>  > -- David Pacheco, Sun Microsystems Fishworks.    http://blogs.sun.com/dap/
>  >
> 
> 
> -- David Pacheco, Sun Microsystems Fishworks.    http://blogs.sun.com/dap/
> 


-- David Pacheco, Sun Microsystems Fishworks.    http://blogs.sun.com/dap/



      
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to