Memory utilization and tunning in TRU64

[Pieter 't Hart]

regarding
SVRMGR> ORA-27102: out of memory
Compaq Tru64 UNIX Error: 12: Not enough space
this link http://www.itags.org/database/234237/ suggests it is a swapspace problem.
Swapspace size is normally sized about 1,5 times physical memory.
Offcourse adding swapspace (virtual memory) will reduce "out of memory" messages.

=========================
But on a databassystems normally you don't want swapping to occur!
=========================
Swapping in/out reduces performance.
So the total memory requested by oracle should be less than max physical memory minus room for other processes including users and batchprocesses.
As you report "Total Physical Memory = 2560.00 M" I would suggest to limit the oracle parameters to use max 2GB instead of raising the system limit so swapping will occur.
If your database really needs more memory, you better add physical memory before increasing oracle parameters.



regarding :
ORA-04031: unable to allocate 4248 bytes of shared memory
you need to look also at the shm_max

from the link i posted earlier.
If only Oracle is being used on the system, you can increase the size of shm_max to 4 GB minus 16
MB, that is:
0xff000000 or 4278190080

This should better address your initial problem then increasing oracle using more memory.

[Martin Wolff]

Thank you Pieter,

Regarding swap space i think i am ok (as seen in attached file).

Actually i have done a maint operation this morning. I changed max_per_proc_address_space to 4294967296 and per_proc_address_space to 4294967296.

After that i changed oracle init.ora shared_memory_size to 150M and the database restarted fine without problema.

Now a few hours later, the main aplication running in the server started telling it was out of memory, and stopped working correctly.

Shared memory is set to 2139095040 ~ 2GB so i guess that´s not a problem also.

We went back those two parameters to the original values 536870912, and the shared_pool_size back to 100MB and the system went back to normal.

I checked vmstat -P and there were still free pages left at the moment of the failure, so i am confused and in a big trouble!!

Any further help will be highly appreciated,
Kind regards,
Martin.

[Pieter 't Hart]

In my opinion 8GB swapspace is extremely large for a system with 2,5G physical memory!
Especially in a database environment.
How many "normal" (non-database) processes are ther on youtr system?

I think you and your DBA need to review the oracle parameters against unix system parameters.

maybe you can post both sysconfigtab and oracle config to review?

My knowledge is from a sybase environment, not oracle.
But maybe i can find some mismatch.

[Martin Wolff]

Hi Pieter,

There are ~20 non database proceses.

By the way, i made a terrible mistake when changing the max_per_proc_address_space to 4294967296 and per_proc_address_space to 4294967296.

I did the operation with:
"sysconfigdb -u -f stanza-file proc", i put a u!!! instead of m!!! So all proc parameters except the ones i put in the stanza file were set to very low values(defaults?)

I have changed them to the values in the attached file and now the system is working for 8 hours without any proccess complaining about lack of memory.

I still do not know what was the Kernel parameter that made the aplications fail to get memory, but for sure i made a terrible mistake.

Thank you very much Pieter,
Kind regards,
Martin.

[Martin Wolff]

I have attached the memory usage of one of the machines with trouble, it looks ok as far as i understand.

[Pieter 't Hart]

Hi Martin,

sysconfigdb should make a (numebered) backup before applying changes.
Have you checked if there are any sysconfigtab. files present?

If so you may be able to retrieve the missing sysconfig parameters.