[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: /dev/shm - when should I use it or not use it?



On Tue, 2007-06-26 at 10:27 -0700, Daniel Northam wrote:
> Hi all,
> 
> I have been doing some searching on /dev/shm and can't find anything
> that provides information on how much ram you should use for /dev/shm.
> one post said that you should use all of your ram. if your system has
> 8GB then make /dev/shm 8GB and if you have more than 2GB of ram you
> would notice a huge performance boost.
> 
> my question is; if that is true then why is it not the default? 
> 
> Anybody have feedback??

I have no idea where the logic for this comes from, but it seems
nonsensical.  /dev/shm is for POSIX compliant shared memory and very few
applications even need/use this.  Even when they do, the memory is
allocated as needed, not all up front.  Remounting with a larger value
only increases the maximum that can be used, not the amount that is
actually used.

Most disto's mount a tmpfs filesystem at /dev/shm with the default mount
options which typically means that /dev/shm will have a max size of 1/2
of your physical RAM.  It's extremely unlikely that your system would
use even of fraction of that (some exception are possibly running Oracle
or SAP).

Most systems use very little shared memory, you can run 'ipcs -m' to see
how much yours is currently using, my guess is it will be in the
megabytes, not gigabytes.  Even less actually use POSIX shared memory,
probably none in the vast majority of cases.  When you run 'ls /dev/shm'
do you see any files?  If not, nothing using it at all.  

Now, I have friends who do things like configure their compiles to use
the tmpfs filesystem on /dev/shm, which basically means they're doing
the compiles in a RAM disk.  Assuming no other memory pressure it
actually does seem to make things faster since the entire untar and
compile require no actual disk I/O.  Of course, tmpfs is still
swappable, so if there is memory pressure it can still create swapping.

Later,
Tom



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]