Re: HP9000+LVM+Online

Andy Kent (akent@cix.compulink.co.uk) nicely wrote: : mikehunt@algonet.se wrote: : > By taking the four disks that we were spreading : > the database over and turning them into one disk consisting of : alternating : > 1Mb chunks of disk we were able to totally remove our disk bottlenecks : > and realise a 30% increase in system throughput. : The more I think about this the more I can't see how this could have been : the best option (although obviously you're there and I'm not, so...) : Given that your application is very update-intensive, you would want to : take the most possible advantage of the fact that page cleaners do sorted : writes during a checkpoint. : The traditional sound advice of: : no. of disks = no. of chunks = no. of page cleaners : - is very sound and tried and tested: at checkpoint each page cleaner : grabs a disk and does sorted writes to it. Easy. There are two points here. Firstly, the number of pages to be flushed during the checkpoint would be much too large to provide a checkpoint that takes less than 10 seconds. As the updates to the database come from up to 30 operators at a time all keying account numbers, amounts etc., from cheques at speeds that are frightening, any checkpoint longer than 20 seconds is a no-no. Secondly, I have never seen more than one page cleaner assigned work during the checkpoint. Given the large size of the disks and the rows being updated at any one time, there is generally only one chunk to be flushed to giving rise to one very overloaded page cleaner attempting to flush many megabytes of updates. To minimise checkpoint duration we keep the MIN_DIRTY and MAX_DIRTY parameters at 15/25 thus keeping the page cleaners more or less permanently active during really busy times. : With alternating 1MB chunks in each logical volume, they'll be switching : from disk to disk the whole time and there's a good chance you'll : sometimes get more than one page cleaner thrashing one another for the : same disk. The only way to completely prevent this would be to configure : just one page cleaner - which of course then becomes a bottleneck in : itself. Indeed, with large checkpoint volumes this could be a problem if the LVM volume was seen by Informix as more than one chunk. However, this massive striped disk is set up as one chunk, one dbspace and would only ever have one page cleaner assigned to it anyway. As I mentioned in my first post, logical log activity was a serious bottleneck most of the time with other areas being bottlenecks throughout the working day. Using LVM in the manner that we have has effectively averaged out all the requirements on the various logical areas in the database. : If there was a lot of read-intensive activity from one big table as well, : then you could always spread its dbspace across Online chunks on : different disks. Yes, but the problem is that the table would only be some 300-500Mb in size and you cannot get enough small disks to split this up effectively. Also, as the data tends to get processed in the order that it is added to the database you still get all the updates heading towards the same disk. : Maybe on the read side your striping method has some advantages, but I : can't see how it can do anything but harm you on the write side. : But as ever, I'm open to being proved wrong. Tell you what, if the guys at the site still have all the excel spreadsheets showing exactly how the various disks were loaded I'll send them on to you. They make *very* interesting reading.