L3000 Vs. Oracle 8.1.7.4 low performance

[Jose Mosquera]

At the moment we are having problems of machine performance since we update Oracle from 8.1.7.0 to 8.1.7.4, and parallelly we place in production this it box as primary node of ServiceGuard (A.11.14). From that moment we have noticed that the free memory has decreased considerably and that the swapper daemon is frequently in the first page of the top's command. In the past (Oracle 8.1.7.0) we had a similar problem with the swapper daemon and we solved it tuning the "dbc_max_pct" kenel's parameter.

I could also note that the idle percentages of the processors (3) are high while this problem happens.

Perhaps the available physical memory is too low for the Oracle's new version, we are working below the recommended minimal ranges to HP-UX 11 (64).

However I would know how to thank you any useful tip/clue to improve our current situation.

Pls find attached our current kernel's configuration and below I detail other interesting parameters:


#swapinfo -mt
Mb Mb Mb PCT START/ Mb
TYPE AVAIL USED FREE USED LIMIT RESERVE PRI NAME
dev 4096 500 3596 12% 0 - 1 /dev/vg00/lvol2
dev 6144 497 5647 8% 0 - 1 /dev/vg00/lvol3
reserve - 3166 -3166
memory 3132 1132 2000 36%
total 13372 5295 8077 40% - 0 -


Machine Model: 9000/800/L3000-5x
CPU Version: 2.0 PA8600
Clock Frequency: 550 MHz
Memory Information:
physical page size = 4096 bytes, logical page size = 4096 bytes
Physical: 4194304 Kbytes, lockable: 3199352 Kbytes, available: 3676280 Kbytes

Rgds.

[John Palmer]

Wee it certainly seems as though you have memory problems though I don't believe that either the Oracle patch install or serviceguarding would have caused this.

Could it be that you've simply got many more users on the system (each Oracle client process uses memory)

I'd suggest using glance (install the evaluation copy from your App CD if you don't have it already). This will give you much more information than top.

Regards,
John

[Jose Mosquera]

Hi John,

Some other tracing tool different to Glance?

Could the sar command be useful?

Some other suggestion?

Rgds.

[Decio Miname]

You could check "sar -u" to check if you have an I/O (usually disk) bottleneck and have more information regarding the idle thing you described. Lots of swapping due to physical memory constraint would reflect on cpu load also, and would be very visible at "vmstat" (as page in/out, etc). I suggest you run "sar -u 1 10" and "vmstat 1 10" at the moment the problem is occurring to check that.

[Decio Miname]

You could use "sar -u" to check if you have an I/O (usually disk) bottleneck and have more information regarding the idle thing you described. Lots of swapping due to physical memory constraint would reflect on cpu load also, and would be very visible at "vmstat" (as page in/out, etc). I suggest you run "sar -u 1 10" and "vmstat 1 10" at the moment the problem is occurring to check that.

[Patrick Wallek]

You are definitely have some memory issues. You are swapping like crazy and that is going to make performance go to hell real fast!

A couple of options:

1) Check you dbc_max_pct parameter and if it is still at 50 (BAD) change it! Something like 10 is probably more reasonable. Note that this will require the kernel to be rebuilt and the machine to reboot.

2) Get MORE RAM!!! 4GB is not bad, but more would be better.

[A. Clay Stephenson]

Because you are experienceing memory pressure, the obvious answer is to increase memory. The one thing that I would do immediately is go find the DBA's and have them reduce the size of the SGA. All the database caching in the world does little good if the processes which access that cache are non resident. You are going to have to tradeoff some database efficiency for process space. On a related note, I have found no performance hits going from 8.1.7.0 to 8.1.7.4 and when you read the release notes for 8.1.7.4, fixes for data corruption are mentioned. That definitely gets my attention and makes the upgrade imperative.

If you are concerned about the high cost of additional memory, look into 3rd-party suppliers. I have found very reputable sources for memory that literally cost an order of magnitude less that that from HP.

[Tim Medford]

Hi Jose.

A few years back I upgraded Oracle from 7.4.2 to 7.4.4 and accidentally unconfigured the MTS support within Oracle. The MTS (multi-threaded-server) keeps a pool of connections for Oracle and places constraints on their memory consumption.

The following Monday morning, the the number of connections quadrulped and I started running low on memory.

Not sure if this is what's happening to you, but might be worth checking into.


Regards,
Tim

[Steven E. Protter]

Looks like my dbc_max_percentage is a bit high.

Going to have to do something about that. Sometimes you try to help and you get helped.

SEP

[T G Manikandan]

The situation can be really improved in converting the configuration of the database from a dedicated server to the Multithreaded server model.

Dedicated server model works spawns a seperate process for each client connection and serves the client.
With Oracle 8.1.7 and above each new process occupy a amount of memory around 30MB.
For example assume that minimum there are 30 connections from the users and the applications then(30 * 30)>it should eat some memory.

In the MTS model you can have a defined no .of processes to serve the client.

The other way would be to upgrade the memory on the box


Thanks