- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Re: strange state
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-18-2006 09:13 AM
тАО05-18-2006 09:13 AM
strange state
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:
TYPE AVAIL USED FREE USED LIMIT RESERVE PRI NAME
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.
Lima.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-18-2006 09:29 AM
тАО05-18-2006 09:29 AM
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:
http://www.hpux.ws/system.perf.sh
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.
SEP
Owner of ISN Corporation
http://isnamerica.com
http://hpuxconsulting.com
Sponsor: http://hpux.ws
Twitter: http://twitter.com/hpuxlinux
Founder http://newdatacloud.com
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-18-2006 12:09 PM
тАО05-18-2006 12:09 PM
Re: strange state
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-18-2006 03:43 PM
тАО05-18-2006 03:43 PM
Re: strange state
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
T ID KEY MODE OWNER GROUP NATTCH SEGSZ CPID LPID
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:
CPU TTY PID USERNAME PRI NI SIZE RES STATE TIME %WCPU %CPU COMMAND
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-18-2006 08:02 PM
тАО05-18-2006 08:02 PM
Re: strange state
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-18-2006 08:25 PM
тАО05-18-2006 08:25 PM
Re: strange state
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.
Regards,
Ninad
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-18-2006 08:37 PM
тАО05-18-2006 08:37 PM
Re: strange state
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.
Anyway:
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-18-2006 11:17 PM
тАО05-18-2006 11:17 PM
Re: strange state
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;
+20% OVERHEAD
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 congets.name='consistent gets'
and dbgets.name='db block gets'
and physreads.name='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 ec.name='execute count'
and pc.name='parse count (hard)'
PS: ├Г┬й isso a├Г┬н meu irm├Г┬гo. :)
Best Regards,
Eric Antunes
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-19-2006 03:29 AM
тАО05-19-2006 03:29 AM
Re: strange state
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.