shmmax with Oracle Applications on hp-ux 11.11.

[Alzhy]

Agreed Hein, I actually never have seen any actual metrics as to how Oracle performs when SGA is in just 1 SHM segment or some "saner" number of segments. The suggestion to set SHMMAX to as large as VM is more largely a safety net for malformed and misbehaving applications (and instances?)so we as admins can analyze effectively during such situations. My rule of thumb is to always ask the DBA's what biggest SGA is expected on a system and set it to that value. We also set a minimum of 1. But I guess with 11i with cooked Filesystems - the norm these days is to always have the biggest SGA that can possiby be allocated for an instance. I leave it out the the HPUX doctorates and laureates to have a more exhaustive assessment of which is correct.

[Jeff Schussele]

Hi Hein,

With all due respect I believe you're wrong.
Do you have any idea the costs associated with the shmset(), shmget() & shmat() system calls? Simply imagine a process needs to attach to 10 shmem segments & another needs to only attach to one. Which one do you think will be faster? Then the overhead associated with working down through process structures that are attached to 10 separate shared memory segments as opposed to only one. Again which one will be doing more work in your opinion? And remember this will all be System CPU time which will be stolen from the User CPU time.

I really think you'd benefit from attending one of the great HP classes like HP-UX Internals or even the Performance & Tuning Class.

And here's a great paper from Stephen Ciullo that is very informative:

http://h21007.www2.hp.com/dspp/ddl/ddl_Download_File_TRX/1,1249,280,00.pdf

Rgds,
Jeff

[Jean-Luc Oudart]

Jeff,

as I said this a high water mark only.

The right process should be proper planning and communication between Sysadmin and DBA.

Rgds,
Jean-Luc

[Jeff Schussele]

I neglected to also give credit for that Perf Cookbook paper to:

Doug Grumann, HP Performance Technology Center R&D lead engineer.

Stephen Ciullo is an HP Senior Technical Consultant & widely recognized as one of HP's best Performance experts.

Jeff

[Hein van den Heuvel]

My experiences, where absolutlely no measurable difference where found between a single versus 'a few' sections, come from
an SAP on Tru64 Unix environment.
Admittedly this is somewhat of a special case as SAP production sites have (very) long lasting DB connections.

Indeed if one were to frequently create slaves then having too many section will increase system time during process activation.

But, IMHO, adjectives like 'devastating' are a bit over the top to describe those effects and will set the wrong expectations.

I'm all for speeding up every single possible component in a system. But if attaching to the SGA has become a critical bottleneck in an application then I suggest that such application is overdue for a design review. Such application perhaps needs a transaction manager component or server slave tasks or whatever..

fwiw... on NUMA platforms, with a Numa aware oracle build, then whole picture changes as Oracle will create many more sections to fit in with the Numa environment.


Cheers,
Hein.

[Jeff Schussele]

Well if one would consider "devastating" a bit over the top, then one would have to consider terms like "baloney", "ghosts", "wild" & "insane" way over the top.

You really need to study PA-RISC architecture to understand how it handles memory mangement & process management structures & then further down into process structure layouts to have a good understanding as to just what impact - and the extent of such - would & will be caused in the scenario as I laid it out.

And as a side-note, this was an actual "real-world" scenario experienced by an actual HP customer. This was & is not theory. They had *serious* performance issues until the issue was solved by upping shmmax from 1GB to 10GB.

Rgds,
Jeff

[Todd McDaniel_1]

Stuart,

Having read your post again, I noticed that your have double the swap of your memory. If I can be so bold, I might suggest you can reclaim 50-75% of that space and opt for a bit more memory. Swap never needs to be larger than memory in my opinion and/or your /var/adm/crash FS.

My systems are configured for about 20% to 50% swap based on memory. The opposite ratio you have.

Regarding your question about shmmax, mine is configured at 1,073,741,824


My Superdome system is setup as such:

SWAP: 36GB
CPU Count: 48
CPU Speed: 750 MHz
CPU HW Support: 64-bit
Kernel Support: 64-bit
RAM Size: 73152 MB
bufpages: 2926 MB
maxuprc: 25320
maxvgs: 64
maxfiles: 2088
max_thread_proc: 256
nfile: 100010
nflock: 2448
nproc: 30000
ninode: 37332
shmmax: 1073741824
shmmni: 8192
dbc_max_pct: 4


MY N-class is setup as such:

SWAP: 5GB
CPU Count: 8
CPU Speed: 550 MHz
CPU HW Support: 64-bit
Kernel Support: 64-bit
RAM Size: 32768 MB
bufpages: 1310 MB
maxuprc: 4000
maxvgs: 255
maxfiles: 500
max_thread_proc: 256
nfile: 29539
nflock: 4096
nproc: 16020
ninode: 18468
shmmax: 1073741824
shmmni: 220
dbc_max_pct: 4

[Alzhy]

Todd, Is'nt it the maximum swap in an HPUX system is still at 32 GB?

Ours is set to be all 32 GB "regardless" of installed RAM since we are employing the 6-disk boot subsystem (mirrored root disks, mirrored exclusive swap disks, an ALTROOT disk and a hotspare disk).

And since we're using Cooked FIlesystems with DirectIO and RAW devices for ORacle Store ... our DBA's are maxing out SGA sizes .. so the reason for the 'enormous' SHMMAX declarations...

[Jeff Schussele]

Hi Nelson,

Absolute maximum swap in 11i is now 2TB.
That's if swchunk & maxswapchunks are at their max.
I have a system that I had to set swap at 128GB so all the applications could reserve when they start. They don't ever deactivate (swap) they just needed the reservation space. And yes they are rewriting it to not be so piggish when they start up.

Rgds,
Jeff

[Todd McDaniel_1]

I think for PRIMARY Swap it is 32GB max but you can have any amount of ALTERNATE swap, if I recall correctly.

Not sure what our DBAs use for the SGA size.