Re: Using TMPFS for /tmp and /var/run?

From: jb <jb.1234abcd_at_gmail.com>
Date: Sun, 1 Apr 2012 19:54:51 +0000 (UTC)
Rainer Duffner <rainer <at> ultra-secure.de> writes:

> 
> Am Sun, 1 Apr 2012 09:40:25 -0400
> schrieb Gary Palmer <gpalmer <at> freebsd.org>:
> 
> > Other than catching software that mistakenly assumes /tmp
> > and/or /var/run is persistent, what are the CLEAR advantages for
> > changing the default?
> 
> It's my understanding it improves performance in cases where lots of
> files are created and deleted in /tmp (and/or /var/tmp - sometimes
> software hard-codes these locations...).
> ...
> OTOH, on new installs, a TMPFS could be used automatically if memory >=
> 4GB.
> ...

There are memory management subsystem considerations against utilizing
tmpfs (memory + swap) for /tmp:
- only part of the program needs to be in the memory for execution
  Delayed and hidden demand for memory.
- demand paging
  Bring a page from swap into memory only when it is needed.
  Delayed and hidden demand for memory.
- Copy-on-Write
  Initial sharing of memory by processes.
  Delayed and hidden demand for memory.
- thrashing
  Excessive in/out swap utilization.
  Very high page-fault rate -> low CPU utilization -> OS thinks it can schedule 
  more tasks -> another process added for execution
- memory overcommit
  Physical memory overcommit resulting in paging; swap space pre-reservation
  Due to it, on heavy loaded systems processes dying on memory pressure.
- Out-of-Memory (OOM) killer
  Due to it, on heavy loaded systems processes dying on memory pressure.

There is a potential for overlapping and multiplying effects from the above and
possibly other factors.

If somebody wants it, despite all dangers to efficiency and stability of their
system, let them make that choice. After all, what real pros are known for is
that they know why and how to customize their systems for a task.

To offer it as a default setup is not called for, regardless of memory plus
swap sizes.

jb
Received on Sun Apr 01 2012 - 17:55:13 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:25 UTC