gh_chunks way of living ;-)

[Dieu de Belle Fontaine]

Hi everybody,

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

[Hein van den Heuvel]

>>> 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.

[Dieu de Belle Fontaine]

Thank you.
B.R.

[Hamel_2]

Hello,

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.

[Han Pilmeyer]

Just to contradict the last reply.

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.

[Hamel_2]

If I use ssm_threshold on a numa system, I don't know how the shared memory is spread on rads. With rad_gh_regions parameters, I control how many memory is used by rad. ie : if you have 2 rads and you want 1gb of shared memory you say :
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).

[Han Pilmeyer]

That document is being rewritten. I know, since I'm doing it.

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.

[Han Pilmeyer]

To correct myself:

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.

[John Dobbs]

Han,

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

[Han Pilmeyer]

It will be called something like "Tuning Tru64 UNIX for Oracle". It's about to go into the final stages of review (for as far as I'm concerned).