Date: Tue, 27 Nov 2001 21:37:40 +0200 From: Sheldon Hearn <sheldonh@starjuice.net> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: David Greenman <dg@root.com>, Kirk McKusick <mckusick@beastie.mckusick.com>, freebsd-arch@FreeBSD.ORG Subject: Re: Using a larger block size on large filesystems Message-ID: <86603.1006889860@axl.seasidesoftware.co.za> In-Reply-To: Your message of "Tue, 27 Nov 2001 11:14:43 PST." <200111271914.fARJEhn93832@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 27 Nov 2001 11:14:43 PST, Matthew Dillon wrote: | It should be reflective of the absolute worst case type of database | access - a random seek/read. Well, having been unable to run your program, let me post the Postmark results. The results [shown at the end of the message] show that, for file sizes below 2KB, the new defaults (block/frag 16KB/2KB) would have a noticeable impact. I'm not convinced, however, that applications that use a large number of such small files could be considered "mainstream" and think that it is not unreasonable to expect operators of such applications to do some tuning. If you (and whoever else understands more about RDBMS-like operations) are comfortable with the impact of the change on that class of appliations, then this looks like a bit of a no-brainer. Regarding the minimum filesystem size for which the new defaults should apply, I can't really find a filesystem size for which they _don't_ improve performance (and can't think why there would be one). I got down to 128MB and was still seeing performance improvements. David O'Brien suggested on IRC that the concerns probably had more to do with the number of superblocks, which shouldn't be reduced below 2 by default if possible. I think we shouldn't force a filesystem down to 1 cylinder group when it might have had more with a smaller block/frag size. Otherwise, I think it's all systems go for the change! Ciao, Sheldon. Postmark results showing the impact of increased fs block/frag sizes: ===================================================================== File size: TPS (16/2): TPS (8/1): 16/2 %Gain over 8/1: (CPG 89) (CPG 22) 0.5KB-1KB 1041 1136 -8.36% 0.5KB-2KB 1086 961 13.01% 0.5KB-4KB 925 862 7.31% 0.5KB-8KB 781 735 6.26% 0.5KB-16KB 694 555 25.05% 0.5KB-32KB 454 333 36.34% 1KB-2KB 781 961 -18.73% 1KB-4KB 781 925 -15.57% 1KB-8KB 735 714 2.94% 1KB-16KB 714 510 40.00% 1KB-32KB 454 337 34.72% 2KB-4KB 806 781 3.20% 2KB-8KB 781 714 9.38% 2KB-16KB 694 531 30.70% 2KB-32KB 446 316 41.14% 4KB-8KB 735 657 11.87% 4KB-16KB 657 471 39.49% 4KB-32KB 446 312 42.95% 8KB-16KB 641 490 30.82% 8292-32KB 431 294 46.60% 16KB-32KB 416 312 33.33% 32KB-128KB 124 117 5.00% 128KB-128KB 119 109 9.00% File size shows the max and min file sizes for each batch run, with actual sizes evenly distributed through the range (effectively; a PRNG is used). A mixed selection of transactions is used: create, read, write, delete. TPS is the number of transactions per second, taken over the entire lifetime of the batch run, including the initial creation and subsequent deletion of files. A sufficiently large pool of files and number of transactions was selected such that TPS values for repeated runs differed by no more than 2 or 3 transactions for quicker runs, and not at all for longer runs. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86603.1006889860>