Re: Disk Layout recommendation

Jonathan Leffler wrote: > Richard Kofler wrote: > >>Jonathan Leffler wrote: >> >> >>>Neil Truby wrote: >>> >>>>"Jonathan Leffler" <jleffler@earthlink.net> wrote: >>>> >>>>>You don't mention which version of IDS you are using (nor which >>>>>platform), but I assume it is not 9.40. If it were, then I'd >>>>>recommend using large chunks for dbs0 (the main dbspace). >>>> >>>>Why? Just for ease of administration? >>> >>>No, performance. If you have multiple chunks on a single device, IDS >>>will treat them as independent devices when they clearly are not, and >>>will therefore send the disk heads tracking all over the place as it >>>moves between chunks. For example, IDS might read sequentially from >>>both Chunk1 and Chunk2 (which happen to be the only chunks on the disk >>>drive), but at the disk level, it might be reading blocks (tracks?) >>>alternately from the inner part of the drive and the outer part of the >>>drive. With a single big chunk, it won't do that; it will schedule >>>the sequential read from the inner part of the disk, then the outer >>>part of the disk. Of course, the extent to which that is a problem >>>depends on the cleverness of the disk controller, the size of its >>>caches, whether you're really dealing with a single disk drive or >>>whether you've got a logical volume manager in the way, or a RAID >>>unit, or a NAS/SAN system, and so on. But when you have simple disks, >>>having single chunks on them as big as the device should give the best >>>performance. >> >>Here I must jump in. >> >>As Andrew showed us some 14-18 months ago, all modern (i.e. >>10K or higher rpm) disk do track read serialization and are >>able to handle 5 to 6 parallel I/O streams to maximize throughput >>per disk. > > So you'd recommend putting multiple chunks on a single disk if the > disk is fast enough? Assuming you aren't using an LVM or RAID or > something similar to provide a level of indirection? And you'd > recommend this regardless of the fact that if you have 4 chunks on a > disk, then accessing the different chunks requires head movement > across 3/4 of the disk even when each chunk is only say 20% full, > whereas in a single chunk, it might only involve head movement over > 20% of the disk? Yes, that's certainly my experience when running the performance tuning course of a few years ago. Admittedly using disks from some years ago, but my assumption being that disks today handle random IO much better. The example was querying a table in a single dbspace versus fragmenting the same table across 3 dbspaces on the SAME disk. The performance improvement using PDQ was linear. It seems that disks are capable of much better throughput than we give them credit for. So my view is never allocate a single chunk to a single disk. >>Now the biggest advantage of having NOT 1 chunk per disk is that on >>can easily see from monitoring the I/O per chunk, which of the >>chunks must be placed on the fastest area of the disks. > > I can see that you lose some precision in the monitoring. But are you > really sure that multiple chunks on a single disk would really, really > improve throughput? It depends on how you distribute the data within those chunks. So I would say we should be talking about dbspaces rather than chunks, because then you have control over what goes where. I did design a data warehouse disk layout for a customer where we fragmented tables into 8 dbspaces across only four disks. I can't claim to have any hard evidence that this is an optimum layout as we didn't do exhaustive benchmarking (as you don't), but I can tell you that when they are building their monthly data, the disks are waiting on the 4 CPUs! >>Of course, I do know, that monitoring your baby to know as >>much as possible, is not a job for the lazy or noncaring or >>dummy. >> >>But that we were able to get information about almost >>everything is still the biggest advantage of IFX over >>competing products, and it is this fact, which still creates >>the not so small performance difference ifx has compared to >>other SQL DB engines (like 'O' or db2) But only if you have a dedicated DBA, a role that a lot of companies forget about (or try to). Cheers, -- Mark. +----------------------------------------------------------+-----------+ | Mark D. Stock mailto:mdstock@MydasSolutions.com |//////// /| | Mydas Solutions Ltd http://MydasSolutions.com |///// / //| | +-----------------------------------+//// / ///| | |We value your comments, which have |/// / ////| | |been recorded and automatically |// / /////| | |emailed back to us for our records.|/ ////////| +----------------------+-----------------------------------+-----------+