> On 11/09/2007, Mike DeMarco <[EMAIL PROTECTED]> > wrote: > > > I've got 12Gb or so of db+web in a zone on a ZFS > > > filesystem on a mirrored zpool. > > > Noticed during some performance testing today > that > > > its i/o bound but > > > using hardly > > > any CPU, so I thought turning on compression > would be > > > a quick win. > > > > If it is io bound won't compression make it worse? > > Well, the CPUs are sat twiddling their thumbs. > I thought reducing the amount of data going to disk > might help I/O - > is that unlikely?
IO bottle necks are usually caused by a slow disk or one that has heavy workloads reading many small files. Two factors that need to be considered are Head seek latency and spin latency. Head seek latency is the amount of time it takes for the head to move to the track that is to be written, this is a eternity for the system (usually around 4 or 5 milliseconds). Spin latency is the amount of time it takes for the spindle to spin the track to be read or written over the head. Ideally you only want to pay the latency penalty once. If you have large reads and writes going to the disk then compression may help a little but if you have many small reads or writes it will do nothing more than to burden your CPU with a no gain amount of work to do since your are going to be paying Mr latency for each read or write. Striping several disks together with a stripe width that is tuned for your data model is how you could get your performance up. Stripping has been left out of the ZFS model for some reason. Where it is true that RAIDZ will stripe the data across a given drive set it does not give you the option to tune the stripe width. Do to the write performance problems of RAIDZ you may not get a performance boost from it stripping if your write to read ratio is too high since the driver has to calculate parity for each write. > > > > benefit of compression > > > on the blocks > > > that are copied by the mirror being resilvered? > > > > No! Since you are doing a block for block mirror of > the data, this would not could not compress the data. > > No problem, another job for rsync then :) > > > -- > Rasputin :: Jack of All Trades - Master of Nuns > http://number9.hellooperator.net/ > _______________________________________________ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discu > ss This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
