Re: Largest chunk size < largest extent size?!?

In <1993Apr9.134032.13678@mnemosyne.cs.du.edu> aburt@mnemosyne.cs.du.edu (Andrew Burt) writes: >We're moving our data to its production platform, which includes a raid5 >array to house the data. (In regards to the question here about how well >does a raid5 array perform, I'll let you know!) >Now following the advice of the online admin manual, which says "make your >chunks large" (since you can have only a small number of them), I set up >the raid array to be one logical disk as 4Gb (it's 5 x 1.2Gb disks, with >1/5 of it used for parity information). >This is brand new, so I'm just initializing the db on there for the first time. >I go into tbmonitor, do param/init, enter the size of the raid array >(which is 4620858K) and it says (when I try to leave the offset at 0), >that this is larger than the max size for a chunk. >Tech support says chunks can only be 2^20 pages (1048576), and since our >page size is 2k, that's 2Gb for a max size chunk. That is, online uses a >20 bit number for the page# in a chunk. >Umm, guys, page 2-102 of the online 5.00 admin guide seems to imply otherwise, >saying that the max size of an extent is 16M pages (or 32Gb), and since >an extent must be contiguous disk space, it must reside on one chunk, so >one chunk, by implication, must be at least this large. Alan Denney is right. Both limits are correct, it's your implication that's wrong. >Questions: > 1) Is this pure horse-puckey or what? What *is* the size of > the max chunk (in #pages)? > 2) If it's 16M pages, not 1M, then how can I convince tbmonitor > to let me have a rootdbs with 4M pages? > 3) If it's really 1M pages, why?!?!? Shouldn't it be 16M as > the docs imply? Are we being misled here? > 4) How does informix allocate space among multiple partitions? > That is, I could split the 4.6Gb into two 2Gb (or three 1.5s) > but if online is going to try to spread the work evenly among > them, that would *decrease* performance, since it would make the > heads travel quite a bit more since they're on the same physical > units. > 5) How would *you* set up a 4.6Gb disk to work with online? (Bear > in mind, it will be mostly full of data very soon, so any scheme > that relies on it not using it all right now, planning for growth, > etc., is pointless). Also bear in mind the raid array can't > be partitioned efficiently to use less than the 5 drives, so > saying "use one drive for rootdbs and..." won't cut it. Since many UNIX kernels fall over with file_size > 2Gb I would be very unwilling to trust my raw device driver to react correctly with chunks > 2Gb. I would set up four chunks, each one equal to one disk in size (primarily because I'm to lazy to work out the correct size for three equal chunks). This is assuming I wanted to lump everything together in rootdbs, as you seem to imply (which I dont' think I would, even on RAID5). > 6) We actually have two stripes of these (9Gb total, but with an > estimated load of about 7Gb usage), so my plan (unless I get > better advice from netlanders) will be to > (a) assume there's no way to get a larger chunk; Correct. > (b) partition the 2 4.6Gb's into smaller units (say, 1.5Gb); Good as any. > (c) fill them one-chunk-from-raid1, one-chunk-from-raid2, > raid1, raid2, etc.; I don't think I'd bother, I'd be very surprised if you can measure the difference between striping across five and striping across ten. > (d) Hope informix doesn't try to be too clever trying to get > chunks 1,3,5 or 2,4,6 going in parallel. :-( It will, if you give it the page cleaners to do it with. My first stab would be to keep the two arrays separate and allocate one page cleaner per array. Gather statistics, then experiment with two cleaners per array, three per array etc until you find the optimum. (This assumes you don't have access to Asynchronous I/O a la Pyramid, in which case one page cleaner should do it). > (e) Hope I can fit enough chunks What's the problem? You're not going to get anywhere near max # chunks! The above discussion assumes you're going to heap everything into rootdbs, which given two 5-disk stripes is hard to argue against UNLESS (as you imply) you are going to be creating a small number of v. large extents, in which case it would be best to try make chunk size consistent with extent size. Without knowing your desired extent sizes it's a bit difficult to make recommendations, but if the number of large tables is small enough to design to I would go for something like: dbspace # chunks locn Size ------- -------- ---- ---- rootdbs 1 ARRAY 1 sizeof catalogs + sizeof PHYSLOG + sizeof bits&pieces + overhead logdbs 1 ARRAY 2 sizeof Logical Logs + overhead datadbs1 <=8 either sizeof extent + overhead " " " " " " " datadbs<n> <=8 either sizeof extent + overhead This would give you more flexibility for changing your mind if you ever discovered that you needed to. Although this is theoretically purer from the physical tuning point of view, I will be surprised if you can measure the difference unless your database/application design is inherently i/o bound. The other thing to beware of is the assumption I've made that OnLine has the RAID arrays to itself. Are you sure you're not going to need to put swap out there? graeme -- Disclaimer: The author's opinions are his own, and not necessarily those of Pyramid Technology Ltd. or Pyramid Technology Inc. --------------------------------------------------------------------------- -m------- Graeme Sargent Voice: +44 (0)252 373035 ---mmm----- Senior Database Consultant Fax : +44 (0)252 373135 -----mmmmm--- Pyramid Technology Ltd. Telex: Tell who??? -------mmmmmmm- Farnborough, Hants GU14 7PL Email: graeme@pyra.co.uk --------------------------------------------------------------------------- We have the technology. The tricky bit is learning how to use it.