atom feed20 messages in org.freebsd.freebsd-hackersKernel [memory] tweaking question
FromSent OnAttachments
MattApr 4, 2005 11:43 am 
Devon H. O'DellApr 4, 2005 11:49 am 
Marc OlzheimApr 4, 2005 11:49 am 
Joerg SonnenbergerApr 4, 2005 11:51 am 
Dan NelsonApr 4, 2005 11:55 am 
Mike MeyerApr 5, 2005 4:50 am 
gilles chehadeApr 5, 2005 4:50 am 
Dunceor .Apr 5, 2005 4:50 am 
ra...@redshift.comApr 5, 2005 5:25 am 
Peter JeremyApr 7, 2005 1:36 am 
Stijn HoopApr 7, 2005 1:39 am 
ra...@redshift.comApr 7, 2005 1:50 am 
ra...@redshift.comApr 7, 2005 1:51 am 
Zera William HolladayApr 7, 2005 7:24 am 
Robert WatsonApr 7, 2005 12:08 pm 
Michael ShalayeffJul 7, 2005 12:08 pm 
chatonJul 7, 2005 12:08 pm 
Juan J. MartínezJul 7, 2005 12:10 pm 
Juan J. MartínezJul 7, 2005 12:10 pm 
Mike MeyerJul 8, 2005 12:25 pm 
Subject:Kernel [memory] tweaking question
From:Peter Jeremy (Pete@optushome.com.au)
Date:Apr 7, 2005 1:36:29 am
List:org.freebsd.freebsd-hackers

On Tue, 2005-Apr-05 05:26:01 -0700, ra@redshift.com wrote:

options SHMALL= options SHMMAX= options SHMMAXPGS= options SHMMIN= options SHMMNI= options SHMSEG=

These are all reasonably well documented in sys/conf/NOTES. If you want more detail, try a SystemV-oriented Unix book

I understand these control shared memory and how many semaphores the kernel can allocate,

Close - they only control SystemV shared memory. Sane shared memory is available via mmap(2). SystemV semaphores are controlled via SEMxxx options. Posix semaphores are listed as 'experimental'.

but I guess what I'm not 100% clear on is how the kernel uses these resources when it comes to running something like Apache or MySQL on a heavily loaded server.

These values all define limits on the amount of shared memory available system-wide (SHMALL and SHMMNI) and to a single process (remaining options). As far as I can tell, neither Apache nor MySQL use any SystemV IPC on FreeBSD. (The only thing that I've found that does use SHM is X in some modes).

In other words, for something like Apache, how much shared memory is required?

None.

Or what would adding additional shared memory and/or semaphores provide.

Nothing.

Does the default # provided for by FreeBSD create a problem and/or would it use additional ram if allocated?

Actually using SystemV IPC will use additional RAM.

Is there the anyone on the list that has experience with changing these that can provide a clear, down to earth explanation as to their impacts?

I have used them on other Unices but never needed to tweak them on FreeBSD. Before adjusting anything, use ipcs(1) to confirm that they are being used. If you seem to be reaching limits (ipcs shows that you are close to system limits or the applications are reporting allocation errors), then just increase the parameter related to whatever you are running out of.