Memory utilization and tunning in TRU64

[Martin Wolff]

Hi,

I am running an aplication that uses Oracle 8 at a DS-25 cluster running TRU64 5.1B PK4.

Oracle was running out of shared memory so DBAs changed a Oracle parameter in order to let Oracle get more memory. This made the system run out of memory, and Oracle could not start again.

Before telling DBA´s to make the change i checked the output of vmstat -P.

I was told long ago that to check the memory that could be used(free), i should sum the free-pages and the inactive-pages. Is this correct?

Also i have seen that UBC is getting a lot of memory, how can i check if it´s actually using it?.

I know i can reduce the max percentage UBC can grow, but i want to be sure if i will not trigger another issue by doing this.

Thank you very much in advance,

Kind regards,
Martin.

[John Manger · Accepted solution]

I think you mean, the DBAs changed an Oracle parameter and now Oracle can't start ... because its asking for more than the system can give.

What did they change ? If you tell the forum what they changed, we may be able to suggest what other things may need adjusting.

Altering the SGA (?) without considering other parameters is not a good way to proceed ;-)

You may also want to post your /etc/sysconfigtab, and whatever console messages and/or Oracle log messages appeared when Oracle couldn't start.

JM

[Martin Wolff]

Yes that's what i meant. They did that change because they were having problems.
I will gather precise information on the errors and changes.

My goal is to know how memory works at TRU64, and know if i can tune any parameter to optimize memory utilzation, and make the system survive some more years.

Thank you very for your help!

[Martin Wolff]

The problems seen by the people that works with the Oracle 8.1.7.4 database is that the shared-pool was totally consumed.
After changing the shared pool from 50MB to 150MB, the database startup showed:

SVRMGR> ORA-27102: out of memory
Compaq Tru64 UNIX Error: 12: Not enough space
Additional information: 1
Additional information: 514

Before doing this we checked the vmstat -P results and the free-pages + inactive pages ~ 450MB, so i told them to proceed to increase the shared-pool in 100MB. Perhaps that was unwise, but the errors in the database access were preventing, and are preventing the systema to work correctly.

I will post the actual vmstat -P output and the /etc/sysconfig file in the next posts

[Martin Wolff]

ro:/>#vmstat -P

Total Physical Memory = 2560.00 M
= 327680 pages

Physical Memory Clusters:

start_pfn end_pfn type size_pages / size_bytes
0 404 pal 404 / 3.16M
404 327671 os 327267 / 2556.77M
327671 327680 pal 9 / 72.00k

Physical Memory Use:

start_pfn end_pfn type size_pages / size_bytes
404 521 scavenge 117 / 936.00k
521 1681 text 1160 / 9.06M
1681 1939 data 258 / 2.02M
1939 2437 bss 498 / 3.89M
2437 2729 kdebug 292 / 2.28M
2729 2737 cfgmgmt 8 / 64.00k
2737 2739 locks 2 / 16.00k
2739 2755 pmap 16 / 128.00k
2755 4078 unixtable 1323 / 10.34M
4078 4090 logs 12 / 96.00k
4090 11752 vmtables 7662 / 59.86M
11752 327671 managed 315919 / 2468.12M
============================
Total Physical Memory Use: 327267 / 2556.77M

Managed Pages Break Down:

free pages = 3073
active pages = 103235
inactive pages = 57864
wired pages = 62164
ubc pages = 89699
==================
Total = 316035

WIRED Pages Break Down:

vm wired pages = 9432
ubc wired pages = 0
meta data pages = 9747
malloc pages = 36616
contig pages = 3702
user ptepages = 2050
kernel ptepages = 330
free ptepages = 8
==================
Total = 61885

[Martin Wolff]

I am attaching the /etc/sysconfigtab file and also got more precise information about Oracle errors seen before the change.

Precise errors:

ORA-04031: unable to allocate 4248 bytes of shared memory

Then DBAs changed the following parameter:

shared_pool_size = 50M --> 100M

[Pieter 't Hart]

Martin, check this :
"Tuning HP Tru64 UNIX V5.1A and V5.1B for Oracle Environments"

http://h20195.www2.hp.com/v2/GetPDF.aspx/4AA0-9949ENW.pdf

[Martin Wolff]

A collegue has noted the following in the proc subsystem:

max_per_proc_address_space and per_proc_address_space parameters are less than default,

max_per_proc_address_space = 536870912
per_proc_address_space = 536870912

Can this prevent Oracle from taking the space it´s needing?

Thanks in advance,
Kind regards,
Martin.

[Pieter 't Hart]

It could just be your DBS made a mistake about the units of memory allocation.
It could be bytes, 512byte blocks, 2Kbyte pages or even 8Kbyte pages.

if your DBA meant bytes, but the parameter adresses blocks or pages, the result will be obvious.

You could also generate a sys_check output?
It will advise you about current environment and advise system parameters.
It my even recognize the Oracle environment and advise accordingly.

I know many administrators want to be in control themselves, but ist's a helpfull tool.
Especially it helps checking relationship between parameters.
you'll allso find many statements with options there you can use separately in the future.
If needed use the man pages for explanation.

[Martin Wolff]

Tonight i will modify:

max_per_proc_address_space to 4294967296.
and
per_proc_address_space to 4294967296

And i will run the sys_check utility, as i started it at 15:30hs and my system CPU utilization increased too much for a busy hour.

I will check the output of sys_check, but is there any way you can tell me if Oracle is getting trouble to allocate memory at startup because of this parameters or any other Kernel parameter?

In your experience, what Kernel params can be producing the Oracle

SVRMGR> ORA-27102: out of memory
Compaq Tru64 UNIX Error: 12: Not enough space

?