possible memory configuration problem

[P. Mijnheer]

Hello,

Whe have a HPUX server rp5470 with 6 GB internal memory the swapspace on disk is 1 GB
Whe having some problems with an application, the error file has the following TSSQLERROR>ORA-12540: TNS:internal limit restriction exceeded. The application manufacture advise us to increase the swapfile 2 times internal memory (12GB), but when i monitor the server the buffer cache isn't decreasing and sar shows no swapping at all. The performance of the server is good.
We are not sure that the advise of our software manufacturer solves our problem bij changing memory-parameters We think by looking at measured data we don't have a memory problem at all. Are we right ??
swapinfo :
Mb Mb Mb PCT START/ Mb
TYPE AVAIL USED FREE USED LIMIT RESERVE PRI NAME
dev 1024 0 1024 0% 0 - 1 /dev/vg00/lvol2
reserve - 1024 -1024
memory 4775 3915 860 82%
total 5799 4939 860 85% - 0 -
I think that this isn't the problem, can anyone advise me

Thanks

[Massimo Bianchi]

Here is an extract from metalink regarding this issue, are other points corrects ?

usually, a minimum of 1/1 ratio between memory and swap is raccomended for best performance.

Check also your dbc_min_pct, dbc_max_pct, good values for oracle are 5/8.

But i don't think that it's a memory problem, chech the other parameters first.

BTW, oracle 32 or 64 bit ? If 32bit, nothing beyond 2G is usefull...


################################

Document ID: 105718.746
Title: UNIX: ORA-12540 and SQL*Net V2
Creation Date: 13 May 1994
Last Revision Date: 15 March 1995
Revision Number: 1
Product: SQL*Net
Product Version: V2
Platform: UNIX
Information Type: SOLUTION
Impact: HIGH
Abstract: This bulletin explains the possible causes for an
ORA-12540 on Unix.
Keywords: SQL*NET;V2;12540;UNIX;NETWORK
-----------------------------------------------------------------------------

UNIX: ORA-12540 and SQL*Net V2


Error text:
===========

ORA-12540, 00000, "TNS:internal limit restriction exceeded"
Cause: Too many TNS connections open simultaneously.
Action: Wait for connections to close and re-try.


Solution Explanation:
=====================

- An ORA-12540 can be a result of the processes parameter in the "init.ora"
being too low. Processes should be set to the number of background
processes plus one for each connection to the database.

- If the "init.ora" processes parameter seems ok, then you may need to
increase the Unix kernel parameters for the maximum number of processes or
users (for example, nproc or maxuprc). Check the manuals for the Unix
operating system that you are using for the correct parameters.

- The ORA-12540 can also occur if you do not have enough swap space. You may
need to increase your swap space.

- If SQL*Net V2 is installed, by default a direct connection will try to go
through the BEQ adapter that is installed automatically when you install
SQL*Net V2. If you don't necessarily want to connect via SQL*Net V2 and you
have the SQL*Net V1 Pipe driver installed, set the environment variable
TWO_TASK: setenv TWO_TASK=P:

This is one way to workaround an ORA-12540. Setting TWO_TASK=P: means your
connections will use the V1 Pipe driver, unless a different connect string
is given on the command line. You may ask yourself, how can this work when
there isn't a SID given in the TWO_TASK string? In this case the
"ORACLE_SID" will be resolved in the user's environment.

As for the implications of using a V1 Pipe driver...

- you can only connect to a local database
- you can't connect via MTS

...and in some cases, it's the default already. But that ought to change in
future releases for most Unix platforms, if it hasn't already.

[P. Mijnheer]

The parameters dbc_min_pct = 5 and dbc_max_pct = 50 do you suggest to change it to dbc_min_pct =5 and dbc_max_pct=8 ?
We think that the Server isn't swapping at all why should we change the swapfile size to ratio 1/1 Is it realy neccassary to have a 1/1 ratio between memory and swap ??

[Massimo Bianchi]

HI,
for the swap it's only a general rule. There are many other threads that discuss this, with pro and contro, the last decision is up to you.

If you have not enough swap (1/1 ratio), you cannot use all of your memory, because of memory pre-allocation issues.

For the dbc_max_pct, usually it's an oracle advice to set this parameters, to free up some memory and let the buffering be done by oracle and not by OS.

With oracle and oracle/sap 5 and 8 (you interpreted correctly) are the best advice.

But, returning to your problem, before any change to kernel parameters (that requires a kernel rebuild and a reboot), i will check the other parameters regarding oracle.


Massimo

[Hai Nguyen_1]

You definitely need to bring dbc_max_pct down to 8-10 which is roughly up to 600MB out of 6GB RAM. In addition, resize your primary swap space to at least the size of your RAM (6GB). By looking at the swapinfo output, I can tell that your system consumes a lot of RAM and your swapspace is TOO small to have enough allocated space for each active process.

Hai

[Stuart Abramson_2]

changing the dbc_max_pct to 8 (we use 10) is a GOOD idea. Ohterwise you waste memory on unneccesary buffer cache.Do it.

Having swap equal to a minimum of 1 x memory is a good idea. The OS "reserves" space in swap for every process in memory, so your swap will fill up WAY before your memory and you will get "out of memory" errors in your applications. Do it.

However, neither of these is your problem here. The guy above had the answer about "too many concurrent connections." Fix that problem.

[T G Manikandan]

One is the dynamic buffer cache dbc_max_pct.

The other one is whether you have swapmem_on is set to 1, enabling pseudo-swap.

Revert