On Thu, Jul 12, 2012 at 6:43 PM, David Sommerseth <davids(a)redhat.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
On 01/06/12 19:42, Brian Wheeler wrote:
> On 06/01/2012 12:21 PM, Lennart Poettering wrote:
>> I think most of the noise in this flame thread is due to a
>> misunderstanding how modern memory management works and the
>> assumption that having an explicit size limit on /tmp was a bad
>> thing, even though it actually is a good thing... In fact, we
>> need much stronger limits than what tmpfs currently provides:
>> per-user limits on the usage of /tmp. But that's something for
>> the future...
> I understand how memory management works...which is why this seems
> like a terrible idea.
> Can you provide numbers that show that there is a speed increase
> with this scheme which offsets the amount of change required to do
> this? I haven't seen anything other than "its faster".
> This is change is troublesome for multiple reasons: * It switches
> the semantics of what /tmp is. Its now apparently for small and
> short-lived files. Where small and short-lived are defined based
> on the RAM usage at the time a file is created. Hooray for
> heisenbugs! * everything that did use /tmp now should use /var/tmp
> which means patching a ton of programs and hoping that third party
> applications do the same thing. So the "problem" this fixes with
> /tmp now exists in /var/tmp. * there are no numbers which back up
> the purported benefits * file data gets moved out of RAM (in this
> case, to swap) not when it is convenient for the kernel at a
> potentially idle time but when the kernel is experiencing memory
> pressure. * changing the amount of space available in /tmp means
> screwing with swap files
> How is this change a win?
I sense a long term strategy ...
a) Move /tmp to tmpfs
b) all programs using /tmp uses /var/tmp
c) all failing programs enforces $TMPDIR to be set to /var/tmp
d) Somebody discovers that /tmp is no longer in use - and propose to
remove /tmp all in all
But we're just at the beginning...
Having that said ... I really see some benefits of /tmp on tmpfs, but
for large workloads which depends on /tmp or $TMPDIR it will be a
pain, no matter what, IMO. And it strikes me as interesting that
Solaris have been doing a similar tmpfs approach for years; yet still
the thumb-rule seems to be "get rid of that ram-fs-stuff and put /tmp
on a real drive". And I wonder why........
A couple of times (several years ago now), I've experienced /tmp being
filled up with junk - and at that time /tmp was a part of /. And that
caused even more fun challenges. So I started deploying /tmp on a
separate LVM logical volume, with a restricted space. Since that
time, all systems have been running quite stable - despite /tmp
getting filled up from time to time. But that's usually not a problem,
as in worst case that misbehaving program just dies.
But I'm really curious to see what happens if this happens on a tmpfs
based /tmp. If you have 4GB RAM server and a 4GB swap ... and then a
program hits the system creating 8-9GB of trash in /tmp ... how will
that impact the performance and responsiveness of the overall system?
How will applications reading data from these memory pages being
swapped out behave (in a performance, point of view) Will OOM killer
at some point kick in? And if OOM killer starts, I'm curious which
processes it will pick to kill ... I imagine this to be particular
funny if you're running something RAM intensive, like something Java
based (JBoss anyone?).
Again.. tmpfs is restricted to half the RAM size by default. You can't
store 8-9GB of trash.. only 2GB, which might land on swap over time.