On Mon, 2009-01-26 at 00:01 -0500, Oleg Drokin wrote: > Hello! In addition to Oleg's suggestions...
> Essentially what is happening is your drives are only able to sustain > certain > amount of parallel i/o activity before degrading the performance due > to all the > seeking going on. Ideally you need to set the number of ost threads to > this > number, but this is complicated by the fact that different workloads > (as in > i/o sizes) result in different parallel streams the drives can handle. Understanding the performance of your storage hardware is exactly why we always recommend profiling it with the lustre iokit -- ideally, prior to deployment of the filesystem. The obdfilter-survey specifically profiles the overall throughput of your hardware while the sgpdd-survey profiles individual disks. The former is supposed to be usable, non-destructively, on an existing fileystem, however the latter is absolutely destructive and should not be run anywhere you want preserve existing data. Now, I mention the non-destructive nature of obdfilter-survey with trepidation. That is it's intent, and for the number of times I have used it has proven to be as advertised, however I am doubtful that that specific aspect gets regularly tested by our QA department and as such there is always a possibility of a bug sneaking in which voids that intent. Proceed with caution. Anyway, the obdfilter-survey simply sends ranges of workloads to your OSTs, varying in thread counts and I/O sizes. When it's all done it gives you a (figurative, or graphic if you use the plot scripts on teh data) picture of the performance abilities of your storage hardware and will show you where the saturation points are. b.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Lustre-discuss mailing list [email protected] http://lists.lustre.org/mailman/listinfo/lustre-discuss
