Re: HP9000+LVM+Online
Posted in 1995
Andy Kent (akent@cix.compulink.co.uk) wrote: : In spite of numerous mildly-provocative postings in this conf, I have yet : to receive a response which has a kind word to say about RAID or LVM. The : V6.00 OnLine manual devotes a page to LVM but doesn't seem to come up : with anything kinder than along the lines of "(mostly) harmless" Oh well, I suppose someone has to put in a good word for LVM then. I'll try to address your individual points first. : As I understand it (and all my experiences prove it), the way to : configure OnLine is with as many separate raw devices as possible. Yes indeed. It is fairly obvious that the more devices your database is spread across the better as there is more concurrency and less contention. [snip] RAID is terrible for databases. HP publish an excellent document (which I have somewhere at home) which details the performance of various types of disk subsystems under varying test situations. The first thing that comes across very clearly from these tests is that RAID performace on a 2K block and random read/write is abysmal. As this is a generally accurate model of what an Informix database is doing it would follow that RAID is a bad choice. In comparative tests that I have performed between SCSI2 and RAID drives with Informix and HP 877 machines, database performance was well over three times faster on the SCSI drives than the RAIDs. Although great increases in performance can come from splitting the database over many disks there are fundamental limits to what can be gained from this approach. Let me elaborate from our experience: Our application is the most database unfriendly thing you have ever heard of. Every working day we insert about 250,000 rows into one massive table, update them all at least three times (50% of them about six times) and then throw them all away at the end of the day. All this is done with buffered log and tbtape constantly backing up full logs to tape. As you can imagine, this imposes some considerable load on Informix! The problem with purely optimising performance of this kind of system by splitting the database across more disks is that you cannot get enough small (<50Mb) disks to make the exercise particulary worthwhile. Some dbspaces, like the physical and logical logs, have so much activity on them it is more than one physical disk can cope with and it is impossible to split these spaces over multiple disks by conventional means. This is where LVM comes in. 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 most essential thing to make this work is that you have every single LVM patch that HP has released installed. Otherwise it will all fall over in a very undignified heap! One the subject of data security, using LVM mirroring instead of RAID is (although more costly) a performance enhancing solution as LVM is capable of sending a read request to the least busy device. This has a significant effect on read performance. Using Informix to do the mirroring is pointless. That's my 2 kroners worth anyway! Mike.