Hello Matthew, Tuesday, August 8, 2006, 8:08:39 PM, you wrote:
MA> On Tue, Aug 08, 2006 at 10:42:41AM -0700, Robert Milkowski wrote: >> filebench in varmail by default creates 16 threads - I configrm it >> with prstat, 16 threrads are created and running. MA> Ah, OK. Looking at these results, it doesn't seem to be CPU bound, and MA> the disks are not fully utilized either. However, because the test is MA> doing so much synchronous writes (eg. by calling fsync()), we are MA> continually writing out the intent log. MA> Unfortunately, we are only able to issue a small number of concurrent MA> i/os while doing the intent log writes. All the threads must wait for MA> the intent log blocks to be written before they can enqueue more data. MA> Therefore, we are essentially doing: MA> many threads call fsync(). MA> one of them will flush the intent log, issuing a few writes to the disks MA> all of the threads wait for the writes to complete MA> repeat. MA> This test fundamentally requires waiting for lots of syncronous writes. MA> Assuming no other activity on the system, the performance of syncronous MA> writes does not scale with the number of drives, it scales with the MA> drive's write latency. MA> If you were to alter the test to not require everything to be done MA> synchronously, then you would see much different behavior. Does it mean that instead of creating one pool if I create two pools with the same numbers of disks in summary, and run two tests at the same time each on its own pool I should observe better scaling than with one pool with all disks? -- Best regards, Robert mailto:[EMAIL PROTECTED] http://milek.blogspot.com _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss