RE: linux kernel parameters

You evidently haven't had your coffee this morning.

You specifically stated that "SEMMNS has to be larger or equal to"

The Red hat documentation clearly states along with the Linux source code that a value of "SEMMNS greater than or larger as you put it is irrelevant".

And as I stated the settings can still be correct and I do not agree with you.      

From: oracle-l-bounce_at_freelists.org <oracle-l-bounce_at_freelists.org> On Behalf Of Mladen Gogala
Sent: Saturday, February 13, 2021 10:38 AM To: dimensional.dba_at_comcast.net; oracle-l_at_freelists.org Subject: Re: linux kernel parameters  

No, I do not have the relationship inverted. You have basically confirmed all that I wrote. With or without the trace file, recommendation to have the semaphore parameter set to kernel.sem=3000 32000 3000 128 as the OP has put it, makes no sense whatsoever. You would need 9M semaphores for 3000 semaphore sets with 3000 members each. And let's not talk about SEMOPM which would remain set to 128 and would restrict the maximum number of operations per semop call to 128. It is unclear why would you need the remaining 2872 semaphores in the set.

Furthermore, thanks for bringing the RH page up. I have some experience with C programming and do remember the basics of semop, shmat and the rest quite well so that I'm perfectly aware of the parameter syntax.

On 2/13/21 1:20 PM, dimensional.dba_at_comcast.net
<mailto:dimensional.dba_at_comcast.net> wrote:

You have the relationship inverted in your statement.

"The problem is that SEMMNS has to be larger or equal than SEMMSL*SEMMNI"  

From Redhat

THE SEMMNS PARAMETER This parameter defines the total number of semaphores (not semaphore sets) for the entire Linux system. A semaphore set can have more than one semaphore, and as the semget(2) man page explains, values greater than SEMMSL * SEMMNI makes it irrelevant. The maximum number of semaphores that can be allocated on a Linux system will be the lesser of: SEMMNS or (SEMMSL * SEMMNI).   Again without the trace file we do not know what Oracle support was looking to change with those settings. If it is a semaphore problem and not a semaphore set or semaphore operation problem, then I would say that SEMMNS would also need to be increased to go along with the SEMMSL and SEMMNI increased settings. However, if the problem they are trying to fix is a semaphore set or semaphore operation problem then changing SEMMNS too, may not be necessary. Only the trace file or gdb of the core file will tell.      

From: oracle-l-bounce_at_freelists.org <mailto:oracle-l-bounce_at_freelists.org>
<mailto:oracle-l-bounce_at_freelists.org> <oracle-l-bounce_at_freelists.org> On
Behalf Of Mladen Gogala
Sent: Saturday, February 13, 2021 9:57 AM To: dimensional.dba_at_comcast.net <mailto:dimensional.dba_at_comcast.net> ; oracle-l_at_freelists.org <mailto:oracle-l_at_freelists.org> Subject: Re: linux kernel parameters  

The problem is that SEMMNS has to be larger or equal than SEMMSL*SEMMNI. Ideally, SEMMNS=SEMMSL*SEMMNI and SEMMSL=SEMOPM.

Semaphores are a subsystem governed by a device driver and have certain syntax. No recommendation which doesn't follow that syntax can be valid.

Regards

On 2/13/21 1:22 AM, dimensional.dba_at_comcast.net
<mailto:dimensional.dba_at_comcast.net> wrote:

There are varying Documents in Oracle Support of Oracle troubleshooting problems and some of the values in the notes actually state the value for those 2 parameters can be up to 32000 on RHEL6 (Doc ID 2467427.1).

On most of the Exadatas I manage with out of the box settings (UEL6/7) those values are set to 2048.

-- 
Mladen Gogala
Database Consultant
https://dbwhisperer.wordpress.com

-- 
Mladen Gogala
Database Consultant
https://dbwhisperer.wordpress.com


--
http://www.freelists.org/webpage/oracle-l