-n parameter and semaphores and multiple broker question

[Progress_Guy]

Hi Folks,

Few questions please.

We're upgrading our dbase servers (HP-UX 11) and I'm calculating the various semaphore kernel parameters.

One issue confuses me.

SEMMSL
The maximum number of semaphores allowed per semaphore identifier (semaphore
set) =
(Max-local-users-on-any-databases + Max-#servers-on-any-databases + 4)

I understand the principals fine, but, PSC say that client networking users don't use semaphores, as the server process they hit uses them - fair enough :lol:

But, doesn't the 'Max-local-users-on-any-databases' equate to the -n parameter and the -n parameter dicates how many TOTAL (not just local) users can connect. Or, are you supposed to derive the 'Max-local-users-on-any-databases' by subtracting off the -n how many are going to be remote clients (i.e. not using shared memory), so, say, if -n was 100, but, 60 of these were estimated to be remote then I should use ''Max-local-users-on-any-databases' = 40 for my calculation.

I'm worried, because, currently when adding databases to our overloaded servers we get semaphore issues, which I have previously resolved by dropping the -n on a few databases.

Does this go deeper ? Am I also mis-using the -n parameter. :blush1:

Also please, all our databases (with exception of a couple which are hit by ODBC) use only one broker with the default of 4 servers. Does anyone think these days it's worth balancing our servers between multiple brokers !! Any serious benefits. A typical database has -n 100, a single broker with the default number of servers (i.e. 4). What about sticking with one broker, but, more servers. I'm no UNIX guru, so, these questions are a little beyond my skill set.

Many Thanks.

 

[TomBascom]

When in doubt use the largest number that you can imagine :awink:

Seriously -- there's no good reason to shave the semaphore, shared memory and open files kernel parameters as close as possible. Give yourself a very generous margin. You may use a few extra kilobytes of kernel space but that hasn't been a reason to worry since about 1990.

Use the sum of -n over the databases that you'll have and then add a fudge factor (I've been known to multiply by 10...), not -n minus remote clients plus servers.

Use glance to monitor usage of these resources.

 

[methyl]

I agree with Tom. Go big and forget about it. Using "promon" , "kmtune", and "glance" you can find out the important numbers.
Find out how many semaphores each database is using with the "promon" hidden menu: R&D, 1 (status), 13 (shared resources). My highest "semaphores allocated" figure is about 500, with kernel "semmsl" set at 1024. The kernel parameter which we blew with multiple databases is actually "semmni" (now set to 256 though we only need about 100) which is the pointers to "semmns" and "semmnu" (now both set to 7200 though we only need about 3000). Beware that database buffers "-B" is in database blocks and that HPUX will let you allocate about 1.7 Gb to "-B" whether or not you have enough physical memory. Use "glance" to see: number of open files; "semmni" ; shared memory etc.. . One wet Sunday afternoon you could stop databases in turn and try to account for the resources freed ... or you could get a life!