Oracle IO Problems VA7400 or MOD12H

[Aziz Zouagui]

Greetings,

We are having some IO performance bottlenecks running our Oracle Database on top of Autoraid MOD12H.

We have 2 MOD12H(s) connected to an N Class Server. Every AutoRaid unit has 5 Luns, one unit is dedicated to datafiles and the other unit to indexes. All of this but we still have IO problems.

The vendor is talking us into switching to a VA7400 subsystem. I don't know if this will solve our problems but I surely don't want to spend the money and the time to migrate and find out that we have not done anything.

Has anyone here been in the same situation ? any feedback would be greatly appreciated.

Aziz.

[Ray Brewer]

We currently have 2 databases running on a single Autoraid and are not experiencing any I/O problems at all. We are using only a K580 which should be much slower than your "N" class. I wuold suggest that you look at kernel tuning. Oracle has a document that outlines minimum kernel requirements for running a database on HP-UX. You can find it on their web site or your Oracle DBA's should be able to get ahold of it. There are two parameters that are not in that document that should also be modified, dbc_min_pct and dbc_max_pct. We run them at min=3 and max=5 but you may need to adjust that for your enviornment. Hope this helps.

Ray

[Aziz Zouagui]

These are the kernal params you mentioned.

dbc_max_pct 2
dbc_min_pct 2

How many users are connected to your database on average ?

Thank you for the feedback.

Aziz

[A. Clay Stephenson]

Your 12H could definitely be a bottleneck. It almost certainly is a bottleneck if you have allocated over about 60% of the capacity as LUN's and 50% is my usual limit for optimum performance. As long as you stay below 50% capacity as LUN's, the 12H will stay in RAID 1/0 mode. If you exceed this by much, part of your data will be migrated to RAID5 and you will see performance degradation. The other 'trick' is to fully utilize both external SCSI buses. There is absolutely no benefit to exceeding two LUN's per VG on your AutoRAID. Ideally, you configure each VG as two LUN's of identical size. LUNA's primary path is through Controller X (alternate Y) and LUNB's primary path is through Controller Y (alternate X). You then stripe each LVOL within this VG across both LUN's typically in 64K stripes. Finally, you need at least 8 or so drive modules per 12H for best performance. If you follow these steps, you will be plesantly surprised at how well these old guys will perform.

Now that I've said all this there is a very good chance that nothing hardware or tuning related is going to fix your problem. The vast majority of Oracle performance problems reside in the application's SQL code itself. It is not uncommon for an 10x-20x increase in throughput to result from the addition of a single index. Long before you consider switching hardware take a very close look at the code.

[A. Clay Stephenson]

You used that dumb Tuned Parameter Set that sets timeslice (incorrectly) to 1; set it to 10 immediately.

[Aziz Zouagui]

Could you please explain the timeslice parameter you mentioned, I would really appreciate it.

Thank you for your comments.

[A. Clay Stephenson]

The tuned parameter set that incorrectly set the timeslice value to 1 has been around for a very long time and despite the best efforts of several people it still persists. I think it's finnaly been changed in 11.11 but since I don't use it, I don't.

The best definition of timeslice that I've ever heard was given by Stephen Ciullo. He describes it as "the maximum number of ticks that a process ain't gonna get". What this means is that when timeslice is set to 10, your process will get no more than 10 ticks (9) before voluntarily going to sleep so that other processes
can run. Now it timeslice is set to 1, how many ticks does that allow the process to run?

In this state, the system does context switches and very little else. You will see very strange semaphore behavior and in one extreme case, I actually saw that cursor keys could not be recogized because before the ESC [ C (or whatever) sequence could be processed, the process would sleep and the sequence would be read as three distinct characters because curses could not process the sequence.

Set timeslice to 10 before you do anything else on this box.

[Aziz Zouagui]

I value your input, but it is not as easy as 123. The system is 24/7 and a downtime to recompile the kernel and reboot is not another week away.

Bear in mind that I have used this system for over 12 months now with these parameters. nothing like what you mentioned above.

Is this responsible for the IO problems I am suffering from when the Oracle databases are heavily accessed ?

Again, I can't thank you enough for the feedback you're providing here.

Aziz.

[A. Clay Stephenson]

The best I can tell you is that you are wasting your time doing anything until you rebuild the kernel with an increased timeslice. The problem can be well masked until the system begins to load and then it degrades very, very rapidly.