Re: DISK ARRAY

In article <3a6e050c$1@news.iprimus.com.au>, Andrew Hamm <ahamm@sanderson.net.au> writes >Neil Truby wrote in message <94juea$rmd$1@lyonesse.netcom.net.uk>... >>I use such an array. >> >>In my experience, the disks are so fast, and the effect of the EMC cache so >>great, that i/o service times are very low indeed, typically 8ms below. I >>have therefore seen little benefit to be had from pursuing a laborious disk >>positioning strategy, and paid little attention to the physical location of >>my chunks. >> >>I have seen nothing to convince me that this is a flawed approach *on ny >>systems*. >> > >Possibly so. I read yesterday that ATA disks are now out-performing FW SCSI >and offering bigger capacities. This industry changes way too fast. How wide >are your stripes? Surely 2 is insufficient, but has anyone got a rule of >thumb or numbers showing a decent stripe width that's really effective? > >PS - how do you take advantage of parallelism and fragmentation if your disk >system is behaving like one or two spindles? > Use fragment elimination. If you do not need to read it then don't read it. This reduces the amount data to be transferred and so reduces the amount of disk i/o needed! > > -- David Williams

David Williams wrote in message ... > > Use fragment elimination. If you do not need to read it then don't > read it. This reduces the amount data to be transferred and so > reduces the amount of disk i/o needed! > Just like that? Don't care about physical seek times etc? Oh - see Niel's response ;-)

In article <3a6e2c9d$1@news.iprimus.com.au>, Andrew Hamm <ahamm@sanderson.net.au> writes >David Williams wrote in message ... >> >> Use fragment elimination. If you do not need to read it then don't >> read it. This reduces the amount data to be transferred and so >> reduces the amount of disk i/o needed! >> >Just like that? Don't care about physical seek times etc? > >Oh - see Niel's response ;-) > First reduce the AMOUNT of i/o to do, THEN place it to reduce seek times. I am trading extra CPU time (having to analyse the query and evaluate fragment expressions) for reduced I/O time (reading less from disk) i.e. making Informix smarter in what it reads ! PS For several weeks now I have been spending the bus ride to work thinking. 1. Fragment to reduce amount of data to read 2. Stripe to ensure consecutive pages are read from different disks. 3. Informix uses reads pages (2K) but can sometimes use 'big buffers' (16K) for reading conseutive pages. So what stripe width to use? 4. Chunks can only be 2Gb 5. Tables >2gb ( or it it 32Gb) must be fragmented. With fragmentation + fragment elimination + parallel scans of fragments used + striping what is the best way to do this? A simple approach would be one say xxxGb stripe set split into xxx/2 2Gb chunks, one dbspace per chunk. But then each fragment becomes one large stripe across all the disks and parallel scans become disk thrashing! Ideally we want one dbspace = one chunk = one stripe across a dedicated set of disks but one chunk cannot be >2Gb and disks these days are >500Mb! Hmmm.. > > -- David Williams

David Williams wrote in message ... > Ideally we want one dbspace = one chunk = one stripe across a > dedicated set of disks but one chunk cannot be >2Gb and disks > these days are >500Mb! Yeah - a growing problem - bad pun intended. I think it's time they slowed down (development) or tried something new. What I want to see is a disk with dozens of independent heads so that seek time is a thing of the past. Or have I missed announcements of that teshnologie already?-) > PS For several weeks now I have been spending the bus ride to work > thinking. Luxury! > With fragmentation + fragment elimination + parallel scans of > fragments used + striping what is the best way to do this? > If you come up with some definitive principles, I'd be interested to hear them. Unfortunately for me, too many customers have to use commodity boxes and can't afford glamorous well-designed raid boxes, so considering table layouts across explicit dbspaces on visible spindles will always be necessary, but at least I'm fairly happy with my ritual now. Checkpoints have come down very nicely thank you. I slandered hardware vendors because I've seen a few people, for whatever reason, insisting on and going with dud arrangements like RAID 5. Otherwise identical machinery has shown performance differences that backup the slander. I think some people who are IT staff at customers can be difficult to convince too, and perhaps scared to make what could be a controversial decision, which might cop the blame in the event of problems. Protecting their bottoms is very important to so many people. (Hope that gets past the e-mail filters) Since you guys are so convinced about good machinery like clarions etc I'll open my eyes next time one is around and see what I can learn to like. I'm just so cynical of salesmen...

Andrew Hamm <ahamm@sanderson.net.au> wrote in message news:3a6f9d87$1@news.iprimus.com.au... > Unfortunately for me, too many customers have to use commodity boxes and > can't afford glamorous well-designed raid boxes But that wasn't the original question, was it?

Neil Truby wrote in message <94q31j$b9b$1@taliesin2.netcom.net.uk>... > >But that wasn't the original question, was it? > Is that a problem? You don't like subject drift? Show me one mailing list where it doesn't happen.