- Community Home
- >
- Servers and Operating Systems
- >
- Legacy
- >
- Operating System - Tru64 Unix
- >
- Re: Memory utilization and tunning in TRU64
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
тАО02-04-2010 12:10 AM
тАО02-04-2010 12:10 AM
Re: Memory utilization and tunning in TRU64
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-04-2010 11:23 AM
тАО02-04-2010 11:23 AM
Re: Memory utilization and tunning in TRU64
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-05-2010 12:02 AM
тАО02-05-2010 12:02 AM
Re: Memory utilization and tunning in TRU64
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-05-2010 10:32 AM
тАО02-05-2010 10:32 AM
Re: Memory utilization and tunning in TRU64
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-05-2010 10:35 AM
тАО02-05-2010 10:35 AM
Re: Memory utilization and tunning in TRU64
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-08-2010 12:13 AM
тАО02-08-2010 12:13 AM
Re: Memory utilization and tunning in TRU64
sysconfigdb should make a (numebered) backup before applying changes.
Have you checked if there are any sysconfigtab.
If so you may be able to retrieve the missing sysconfig parameters.
- « Previous
-
- 1
- 2
- Next »