Oracle performance

[Johan Bergström]

The be able to give a good answer to the question, I need to mention that we use a EVA 8000 for disksystem to this db server.

To get the best performance in oracle, should I create one lun/disk for the oracle database, or split it up on several, considering I'm using a EVA8000 with a whole bunch of disks underlying all luns/disks ?

I am asking because I have heard rumors about HP-UX have some software limit that only makes it possible to make 8 parallell writes per lun/disk at the time, so if I split it up we could get better performace. Or if this is true, is there a way to modify this parameter somehow?

Thanks.

[Stuart Abramson_2]

Our current policy here is to use 70 GB Striped MetaVolumes (EMC) presented on two paths. The customer has determined that that gives them the performance that they need without having to manage hundreds of 8 GB HyperVolumes.

In the past, I have worked on configurations with as many as 8 paths to several hundred physical volumes of size between 8 and 32 GB (which on EMC disks were usually mirrored HyperVolumes).

There definitely is a trend in the storage business today to larger volumes...

[Dave Hutton]

Unfortunately on an EVA you have no control over the back end side of things. The performance is supposed to be optimized by the EVA itself. You have essentially one large stripped disk system. Throw in virtual raid set groups thats created/maintained by the EVA.

We have an older EVA5000 which our DBA's and QA team are complaining about performance across all (9 hpux and 1 windows) the servers attached to the EVA. So theres a big finger pointing at the EVA that it is not performing as one would hope.

Searching the forums there was a suggestion of lvmstriping your lvols in your vgroup.

Which I've not had a chance to try and see if it works better.

But I would suggest giving that a whirl.

[Jean-Luc Oudart]

Johan

First, I would consider RAID 0+1 and not RAID5 for the database.

Then, I suppose if you want to balance your IOs accross the HBAs you can can use lvm stripping with up to 8 disks (I don't know if there is a limit here or if performance are'nt improving above this number !).
stripe size, we have 64K but you may try bigger.

Regards
Jean-Luc

[Richard Perez]

Johan
the best advice is to create several LUNs instead of a big LUN. This way you can load balance the i/o to the LUNs.

Regarding parallel writes, maybe you heard about scsi_queue_depth, which usually is 8

Regards

[Sameer_Nirmal]

I don't think it is a good idea at all to create only one big Vdisk/lun for oracle.
First of all, the size of the Vdisk/lun doesn't make much sense to EVA from the performance perspective. I believe what matters to EVA is the I/O patterns which are being put on. For example,to allow EVA to perform well and give good I/O throughput , it is better not to mix-up the entirely cross I/O patterns to let originate from a lun. Saying this, you should not have a LUN having both data and indexes of oracle in it.

Refer following document which is performance evaluation of oracle 10g on EVA.

http://h71028.www7.hp.com/enterprise/downloads/Perf_Eval_Oracle10g_HP_SW_EVA.pdf

About : 8 parallel writes per lun
I guess you are referring the scsi-queue depth on HP-UX which is 8 by default ( scsi_queue_depth kernel parameter).
The scsi-queue depth signifies the maximum number of outstanding I/Os would be initiated by HP-UX for a scsi disk/lun. Well, EVA is quite capable of handling much more than just 8 I/Os. Once the luns are used ( with careful planning based on I/O ) , it is always advisable to increase the scsi-queue depth of those EVA luns to 16 to startwith. Note don't increase the kernel parameter which applies globally to all scsi disks/luns.
You can use scsictl command to set the queue depth for individual lun. Be aware that you need to create a script using scsictl command for setting-up this value even after rebooting of the server.

Moreover in EVA 8000, there is active-active controller implementation. So a LUN/Vdisk gets served by the two controllers at a time and you get better I/O throughput for each LUN/Vdisk.

[Duncan Edmonstone · Accepted solution]

Lets just correct something here...

While its true that the new EVA is active/active in terms of vdisk presentation, unlike monlithic disk arrays (such as the HP XP12K, EMC DMX), there is *no* advantage in sending IOs for one vdisk to both controllers. The non-preferred controller will simply send the IOs across the mirror port to the preferred controller (similar to the way the VA used to do it if anyone remembers that).

SO how do you take advantage of the performance of the second controller? Use at least 2 LUNs, one preffered on each controller. What you do with those two LUNs is up to you - either concatenate, or use extent based striping - but I wouldn't advise you to use the normal LVM striping as these small stripe sizes are just likely to confuse the caching algorithms on the array. Extent based striping will have a stripe width of at least 4MB (more if you use a bigger extent size in your VG), so should be big enough not to upset the caching too much, but still leave IOs balanced across the controllers.

Another consideration with Oracle is the redo logs - these don't want to be held up by other IO processing as this *will* slow your database down - therefore ensure that these are on seperate vdisk(s) so they are using a seperate scsi IO queue.

And as others have mentioned - don't forget to set the scsi queue depths at more than 8.

HTH

DUncan

[Matthew Ghofrani]

I agree with all the above and more:
1. The reason companies are going with bigger disks is not performance but rather the price. Indeed smaller physical disks perform better for the applications (with stripping ofcourse).
2. Regardless, the more filesystems you create, the more agents (4 per lvol) the O.S. dispatches to handle the I/O.(Don't go over board with this, as above 128 per VG you loose performance)
3. Defenitely segrigate your redo logs and archive area from the main data.

Matthew from Boston

[Johan Bergström]

Thanks for your help.