Simpler Navigation for Servers and Operating Systems
Completed: a much simpler Servers and Operating Systems section of the Community. We combined many of the older boards, so you won't have to click through so many levels to get at the information you need. Check the consolidated boards here as many sub-forums are now single boards.
Showing results for 
Search instead for 
Did you mean: 

strange state

Regular Advisor

strange state

Hi All,

I have a HPUX 11.11 box with 6 Gb RAM
the Kernel is:
Kernel :
nproc 4096
sema 1
semaem 16384
semmap 4098
semmni 4096
semmns 8192
semmnu 4092
semmsl 2048
semume 512
semvmx 32767
max_thread_proc 2048
maxdsiz 3221225472
maxdsiz_64bit 274877906944
maxssiz 100610048
maxssiz_64bit 1073741824
maxtsiz 1073741824
maxtsiz_64bit 4294967296
maxuprc 3277

I created 1 instance 9.2.0 with 510 Mb SGA but sometimes the system don't have memory to create process. Before, with 8.1.6 we had 2 instances running with no problems!

in this box there are Baan system too.

Sometimes when user try to connect with Baan, they get error: ORA-04031: unable to allocate 25816 bytes of shared memory ("shared pool","unknown object","sga heap(1,0)"," session param values")

I compare the oracle process with Production and developer system (both 9.2.0 same hardware) and I observe that the size of process are different.
In the development system, the oracle internal process have (average) 80 Mb and on production system, they have (average) 800 Mb. The init are "same".

the swap on development system:

dev 1024 0 1024 0% 0 - 1 /dev/vg00/lvol2
dev 2048 0 2048 0% 0 - 1 /dev/vg00/lvol9
dev 2048 0 2048 0% 0 - 1 /dev/vg00/lvol10
reserve - 2058 -2058
memory 1902 1355 547 71%
total 7022 3413 3609 49% - 0 -

the swap on production system:
dev 4194304 0 4194304 0% 0 - 1 /dev/vg00/lvol2
dev 4194304 0 4194304 0% 0 - 1 /dev/vg00/lvol12
reserve - 3238144 -3238144
memory 4351696 874976 3476720 20%
total 12740304 4113120 8627184 32% - 0 -

well, any idea?
thanx in advance.
We are spirits in the material world
Steven E. Protter
Exalted Contributor

Re: strange state


The error indicates a shortage of shared memeory.

What is shmmax and shmseg.

shmmax should probably be increased to 25% of system memory, which hp-ux defines as swap plus ram.

Perhaps check performance:

If there is memory pressure and vmstat shows a lot of pages being swapped in and out, the problem can be solved by buying more memory.

Adding swap will not help the system if swap is being heavily utilized. Based on what you post I don't think swap is a problem here.

Steven E Protter
Owner of ISN Corporation
Bill Hassell
Honored Contributor

Re: strange state

Are you running 32bit instances of Oracle? If so, your memory is severely limited and easily fragmented. There is only one map for 32bit shared memory and all 32bit processes use it. The command:

ipcs -bmop

will show active segments. But even if you had 100Gb of RAM, your 32bit processes afre stuck with a single map. If you use kill -9 to terminate processes that use shared memory, that memory is never returned until you reboot or (very carefully) use ipcrm. 32bit processes can address up to 950megs of shared memory but a single segment (in your case, 510 megs) must exist as a contiguous section. Two or three 300meg sections will not work and your program will state that there is not enough memory.

Note that shared memory is completely separate from local program memory. Your 6Gb of RAM is plenty and you also have more than enough swap space, so there is no need to worry about process size.

There is a program from HP that will map your 32bit shared memory map to show the free spaces and occupied spaces. Fragmentation occurs when small segments are scattered around the map so that no single space is 500 megs in size.

Bill Hassell, sysadmin
Regular Advisor

Re: strange state

Hi Bill,

Oracle 9i (I think) only run in 64 bit. It's correct? I think it in not the problem.

when the system is not on heavy load...
#ipcs -bmop
IPC status from /dev/kmem as of Fri May 19 00:38:16 2006
Shared Memory:
m 0 0x411c025d --rw-rw-rw- root root 0 348 909 909
m 1 0x4e0c0002 --rw-rw-rw- root root 2 61760 909 911
m 2 0x4121a8b9 --rw-rw-rw- root root 2 8192 909 911
m 3 0x301c7913 --rw-rw-rw- root root 3 1048576 3770 4048
m 4 0x501c7589 --r--r--r-- root other 1 1075095 4109 4109
m 517 0x00000000 D-rw------- root root 6 1052672 5694 5694
m 2054 0x00000000 D-rw------- www other 6 184324 6533 6533
m 5639 0x68a25de0 --rw-rw---- ora816 dba 55 571965440 10569 23502
m 37384 0x0192db45 --rw-rw-rw- root sys 19 16777216 11438 23113
m 64521 0x00000000 --rw------- root uagent 2 8393736 23452 23452

One Oracle instance, one Baan shared memory, http...

from Top:

1 ? 11038 ora816 154 20 669M 20308K sleep 1:15 0.02 0.02 ora_pmon_vsdb
0 ? 11040 ora816 156 20 682M 33876K sleep 3:59 0.02 0.02 ora_dbw0_vsdb
0 ? 11042 ora816 156 20 682M 33876K sleep 6:03 0.02 0.02 ora_lgwr_vsdb
0 ? 11046 ora816 156 20 668M 17300K sleep 4:36 0.02 0.02 ora_smon_vsdb
0 ? 11048 ora816 156 20 668M 19604K sleep 0:00 0.02 0.02 ora_reco_vsdb

what do you think about?

We are spirits in the material world
Steve Lewis
Honored Contributor

Re: strange state

My ideas are these:

1. increase kernel parameters:
shmmax 4294967296
shmseg 256
rebuild the kernel and reboot.

2. Whenever you re-start Oracle, reboot the server too, to defragment the memory.

Honored Contributor

Re: strange state

I dont think shmmax and shmseg are directly related to the problem. Because only increasing shmmax wont help as the Oracle SGA would still be 510 MB. Also I dont think there is a problem of fragmentation of memory as can be seen from the ipcs output that a single shared memory segment is allocated to the oracle SGA.
I feel you should try increasing your Oracle SGA size to say 600-650 MB. First check if you are having enough free memory to cater to this increased SGA size - the SGA should be able to fit in your physical memory rather than using swap. For this also check that your shmmax parameter is always greater than the maximum SGA size of the databases running on your system so that a single contiguous segment can be allocated.

Frank de Vries
Respected Contributor

Re: strange state

I agree with Ninad Date.
This error is not kernel related but down to a couple of Oracle initiazalion parameters
that make up the SGA:
Although your kernel parameters must be correct as well so the early advise is not wasted.
The minimum values should be this:
And for every kb you increase java_pool_size,
you must increase the shared_pool_size:

shared_pool_size = 64000000
large_pool_size = 12000000
java_pool_size = 25971520
log_buffer = 663552

After that you should be ok.
Keep cooking
Look before you leap
Eric Antunes
Honored Contributor

Re: strange state

Hi Vogra,

Your SGA should be close to this size:

select sum(sharable_mem) from v$db_object_cache;
select sum(sharable_mem) from v$sqlarea where executions > 5;
select sum(250 * users_opening) from v$sqlarea;

select round((congets.value+dbgets.value-physreads.value)*100/
(congets.value+dbgets.value),4) || '%' "Buffer Cache Hit Ratio >= 95%"
from v$sysstat congets, v$sysstat dbgets, v$sysstat physreads
where'consistent gets'
and'db block gets'
and'physical reads';

select (1-(sum(getmisses)/sum(gets))) * 100 "Hit Ratio (%)"
from v$rowcache;

select pc.value*100/decode(ec.value,0,1,ec.value) "Parse/execute ratio < 3%"
from v$sysstat ec, v$sysstat pc
where'execute count'
and'parse count (hard)'

PS: é isso aí meu irmão. :)

Best Regards,

Eric Antunes
Each and every day is a good day to learn.
Ben Dehner
Trusted Contributor

Re: strange state

For my 2 cents, there are two basic problems. First, the ORA 4031. This error means that the init parameter shared_pool_size is not large enough to support the number of sessions in the database. You need to make it bigger. If there isn't enough system memory to make the shared pool bigger, add some. There's no other way to fix a 4031 error.

Second, apparently the production Oracle processes are taking up 800 MB of memory while the development process use only 80 MB. (Both these seem way too high for me.) This *could* be because of a different usage profile of the production verses developement. I'd personally suspect a memory leak in Oracle. If you have a tool like GlancePlus, you look at each process and see who is sucking up the memory. Otherwise, the worst culprit that I've found is the DBMS_JOB processes, which are spawned if the init parameter JOB_QUEUE_PROCESSES is > 0. You can dynamically recycle these processes and see if it frees up memory:

alter system set job_queue_processes = 0;
-- wait a few minutes for them to stop
alter system set job_queue_processes = ;

As for swap, I would strongly advise having total swap == total memory. Additional swap is a waste of disk; you don't actually want to USE it. However, less swap is very bad. Each process image requires some swap allocation. Once swap fills up, no new processes will be able to run. That is, fork() calls will fail with "Not enough space". At this point, one realizes just how core to the unix OS that fork() really is.
Trust me, I know what I'm doing