Re: High lngspins - IDS 9.30 UC2

On Tue, 21 Oct 2003 20:07:23 -0400, Andrew Hamm wrote: > Art S. Kagel wrote: >> >> Thanks, Andrew. I have not noticed these problems in my own testing but this >> is Clarion City so... Definitely something to investigate going forward. > > In a Clariion world, I doubt you'll see any differences from thread counting. > I've driven the test program from 1 to 50 threads, and the throughput remains > a steady high value. Therefore a Clariion should not suffer from having too > many chunks, because it's on-board processor must schedule the activity to the > optimal values. Yes, fast processor, huge internal cache, excellent algorithms, and very flexible array configuration add up to great sustainable performance. I like the Clariions. (Hey EMC liked them enough to buy the company!) The Clariion F4700 is capable of 50,000 cached IOs/sec with a sustainable 350MB/sec reading through from disk. There are 2 storage processor boards with two processors and two IO channels each and an array can be configured to distribute requests across all 4 channels so the throughput, as you have seen, is awesome. > I don't know Clariion enough to know whether you can deliberately control > which chunks appear on which physical disk (or disk set in the case of RAID) > but if that is reasonable then you should still be able to ensure even > distribution of activity. > > My theory about these high-end, optimised disk boxes is that they mask the > disk activity behind very smart caching, so their max throughput will be > throttled back only by the best performance the disks can offer to absorb the > transfers - ie when a queue gets full, it can only accept more requests as > quickly as the queue empties from the other end. > > Just setting the underlying disk sets to a chosen RAID configuration will > offer the pure performance that such a configuration is capable of, unaffected > by external influences such as number of IDS chunks. One thing we do to reduce/eliminate the possibility of the Clariion internal queues backing up is to maximize the number of spindles in use. IMM we configure 60 drives which as 5 RAID10 arrays of 5 pairs and 10 hot spares. Then we plaid the 5 stripe sets into one huge array bringing 50 spindles into any read request and 25 spindle pairs into any write request. Art

Art S. Kagel wrote: > > One thing we do to reduce/eliminate the possibility of the Clariion > internal queues backing up is to maximize the number of spindles in > use. IMM we configure 60 drives which as 5 RAID10 arrays of 5 pairs > and 10 hot spares. Then we plaid the 5 stripe sets into one huge > array bringing 50 spindles into any read request and 25 spindle pairs > into any write request. Woof! As long as the requests are 50x (or 25x?) stripe size. So your readahead parameters are set to encourage transfers that large? What stripe size do you use, btw? is it configurable on a Clariion?

On Wed, 22 Oct 2003 20:02:57 -0400, Andrew Hamm wrote: > Art S. Kagel wrote: >> >> One thing we do to reduce/eliminate the possibility of the Clariion internal >> queues backing up is to maximize the number of spindles in use. IMM we >> configure 60 drives which as 5 RAID10 arrays of 5 pairs and 10 hot spares. >> Then we plaid the 5 stripe sets into one huge array bringing 50 spindles into >> any read request and 25 spindle pairs into any write request. > > Woof! As long as the requests are 50x (or 25x?) stripe size. So your readahead > parameters are set to encourage transfers that large? What stripe size do you > use, btw? is it configurable on a Clariion? Yes, each physical read is 25x stripe size. Stripe size is configurable as 2K, 4K, 8K, 16K, 32K, 64K, or 128K. Obviously we use a small stripe size and the Clariion cache eats the balance of the physical read so read-ahead is not a problem. Consequently we keep the ONCONFIG RA parameters very low: 8 & 2 or 16 & 2 typically. This prevents unneeded RA from IDS thrashing the cache which has already been primed by the huge physical read. Needless to say when the EMC maintenance guys forget to turn the cache back on after maintenance we notice the difference! Art S. Kagel