On Mon, Jun 9, 2014 at 11:50 AM, Steven Hartland <[email protected]> wrote:
> Nice article Matt. > > Its good to see you recommend using compression for 4 / 8k record > sizes for DB work, as that's something we've used here for quite some > time and it does indeed work well. > > However would you recommend "not" limiting the recordsize for said > DB workloads, or are the benefits still there to be had by limiting to DB > page size in your experience? > For most database workloads, matching the ZFS recordsize property to the database block size will result in the best performance, because the database tends to do random-ish writes of its blocksize. Setting the recordsize to match will eliminate the read-modify-write that you would get with the default recordsize=128KB. > > Also what's your experience tell you when it comes to 4k native sectors > in this area, still use compression? > Compression still helps with recordsize=8k -- some blocks can compress to half the size. However, as I mentioned in the article, if you are using 4K-sector disks with RAID-Z, and most of your data is recordsize=4K or 8K, you aren't getting better space efficiency then mirroring (see the 1 or 2 sector rows of the spreadsheet). --matt > > Regards > Steve > > ----- Original Message ----- From: "Matthew Ahrens" <[email protected]> > To: "developer" <[email protected]> > Sent: Monday, June 09, 2014 6:10 PM > Subject: [OpenZFS Developer] blog post: RAIDZ stripe width > > > > The popularity of OpenZFS has spawned a great community of users, > sysadmins, architects and developers, contributing a wealth of advice, tips > and tricks, and rules of thumb on how to configure ZFS. In general, this is > a great aspect of the ZFS community, but I’d like to take the opportunity > to address one piece of misinformed advice about how many disks to put in > each RAID-Z group. > > Read more on my latest blog post: > > > *ZFS RAIDZ stripe width, or: How I Learned to Stop Worrying and Love RAIDZ* > http://blog.delphix.com/matt/2014/06/06/zfs-stripe-width/ > > --matt > > > > ------------------------------------------------------------ > -------------------- > > > _______________________________________________ >> developer mailing list >> [email protected] >> http://lists.open-zfs.org/mailman/listinfo/developer >> >> >
_______________________________________________ developer mailing list [email protected] http://lists.open-zfs.org/mailman/listinfo/developer
