- Community Home
- >
- Servers and Operating Systems
- >
- Legacy
- >
- Operating System - Tru64 Unix
- >
- Re: gh_chunks way of living ;-)
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
тАО03-31-2005 12:39 AM
тАО03-31-2005 12:39 AM
gh_chunks way of living ;-)
We 've performance problem on a Oracle8i on a Tru64. In doc,they said that it can be efficient to swap ssm_threshold memory management by gh_chunks management when there is a large number of connection/deconnection.
(it's our situation, because we have a large number of very small batch files)
Is there someone who test it in a production environnement ?
I seach also a sysconfig of a working fine a OSF1 V4 on an ES40 with 4 proc/4 Go memory
Thank you all.
B.R.
P.S: It's of course urgent
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-31-2005 01:55 AM
тАО03-31-2005 01:55 AM
Re: gh_chunks way of living ;-)
>>> P.S: It's of course urgent
Then call support!
>> it can be efficient to swap ssm_threshold memory management by gh_chunks management when there is a large number of connection/deconnection.
(it's our situation, because we have a large number of very small batch files)
The reference is more to many concurrent connections than many coming and going.
So, GHCHUNKS is extra efficient with hundreds of corrurently active connections.
It's simple. Every page has a pagetable entry (PTE). You can fit 1024 PTE's ona pages. So at 1000 concurrent maps to the SGA you will burn as much memory mapping the SGA as the actual SGA. And the systems has to maintain those all along. The GHCHUNKs no more PTEs are needed for those concurrent users.
"We 've performance problem "
that's not too much to go on. If that problem is a disk bottleneck, than GHCHUNKS is not going to help one bit. Ditto for bad execution plans, contention, network, ...
If the problem is high cpu time, slow process startup/shutdown, bigh system time, then GHCHUNK may help.
Still GHCHUNK has never been shown to hinder, so you might as well set it up if you have a reasonably stable/predicatble Oracle environment.
Be care to also consider gh_min_seg_size
and gh_fail_if_no_mem. The first can make sure GH only goes to a 'good cause' the second should probably be cleared depending on whether you want to make the system do a best effort, or just die if no GH is left.
Be sure to tail /var/adm/messages when first experimenting with GH.
You may want to consider more recent Tru64 and/or Oracle versions. The BIG PAGES in Tru64 V5.1B is a really neat, flexible, alternative to GH.
Cheers,
Hein.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-31-2005 04:00 PM
тАО03-31-2005 04:00 PM
Re: gh_chunks way of living ;-)
B.R.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-31-2005 08:46 PM
тАО03-31-2005 08:46 PM
Re: gh_chunks way of living ;-)
gh_chunk is usefull on a numa hardware, like GS Wildfire or Marvel because it permits to stripe the shared memory on all rad and so levels the access speed to the data.
I doubt that swapping to gh_chunk memory management on your ES40 increase significaly the database performance.
Let us know if there is enhancement.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-31-2005 09:56 PM
тАО03-31-2005 09:56 PM
Re: gh_chunks way of living ;-)
Granularity hints memory (gh_chunks or rad_gh_regions) has nothing to do with NUMA systems. Even normal (SSM-type) shared memory can be striped. You do not need to use granularity hints memory for that.
There is definitely a performance benefit when using granularity hints memory even on non-NUMA systems.
Oracle has not been certified in combination with big pages. Even though big pages (vm_bigpg_enabled) is the option that offers the best performance, you have to use this at your own risk in combination with Oracle. If you go this route, be sure to use vm_segmentation=0.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-31-2005 11:44 PM
тАО03-31-2005 11:44 PM
Re: gh_chunks way of living ;-)
rad_gh_regions[0] = 512
rad_gh_regions[1] = 512
I have a doc about gh & oracle issue. Here is what it says :
Non-GS series platforms (ES, DS and GS140 systems)
On these systems the gh_chunks tunable is used to configure granularity hints memory. As the overall performance gain using gh_chunks is usually only in the range of 7% it might be not an interesting option for most systems due to its complexity in implementation.
However some systems might still benefit from using gh_chunks, especially ORACLE environments which are having a very large number of clients connecting and disconnecting from the database. In these type of environment using gh_chunks can actually give a significant performance increase. gh_chunks is calculated by dividing ORACLE├в s SGA size by 4MB and then specifiying the value for gh_chunks (ie. setting to gh_chunks = 1000 would allocate 4GB of memory for GH memory).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-01-2005 12:00 AM
тАО04-01-2005 12:00 AM
Re: gh_chunks way of living ;-)
I'm not sure how this suddenly ended up being about NUMA systems. rad_gh_regions will pre-allocate (although that's probably not the right word) memory for shared segments per RAD. That still doesn't guarantee that the memory is actually used that way, although typically it would be. SSM-type shared memory will also be striped (by default) over the RADs in the system. But depending on the load in the different RADs, the system may choose to move that memory around.
Doesn't change the fact that granularity hints memory is usefull for non-NUMA systems too. In fact gh_chunks was implemented long before NUMA systems were introduced.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-05-2005 03:34 AM
тАО04-05-2005 03:34 AM
Re: gh_chunks way of living ;-)
When using big pages (vm:vm_big_enabled=1), be sure to disable segmentation (vm:vm_bigpg_seg=0). vm:vm_segmentation can remain at its default value.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-23-2006 10:30 AM
тАО06-23-2006 10:30 AM
Re: gh_chunks way of living ;-)
You mention re-writing a document. Would that be System Configuration and Tuning for Tru64 UNIX Version 5.1B or higher, dated September 2002? We're using this document to configure GS1280s for Oracle 9.2. We have questions about rad_gh_regions and gh_chunks and would like to look at a newer document if it is available.
Thanks,
John
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-23-2006 11:24 AM
тАО06-23-2006 11:24 AM