Re: Moving /tmp to tmpfs makes it useless
Hi
Now lets do a benchmark on a busy system (during a kernel compile) and
some memory pressure, due to building on tmpfs. While this is not
directly representative for /tmp/ usage patterns, it does show what
happens if /tmp/ gets full and fights against normal RAM uses.
Tested on a current unstable system under KDE 4.7.4, debuild invoked
under 'konsole'. For each test the system was freshly rebooted and is
mostly idle. As an indicator for system responsiveness the only
application running besides konsole && debuild is kaffeine, displaying
a 720*576 DVB-T/ MPEG2 stream.
*system specifications*
- Intel Core2 Quad Q9550, 2.8 GHz
- 8 GB RAM
- ATI RV630 [Radeon HD 2600 Series]
using xserver-xorg-radeon and its firmware
- Seagate ST31000340AS HDD, 1 TB, 7200 rpm
- io scheduler cfq registered (default)
- kernel 3.4.1-rc1
required space for building linux-2.6 3.2.19-1 on amd64 using debuild
on an unclean host, involving a lengthy lintian run (no devscripts.conf
customisation), ~19 GB
*ext4*
single GPT partition spanning the whole disk, freshly formatted with
ext4 (all defaults, empty).
/dev/sdc1 /mnt ext4 rw,relatime,data=ordered 0 0
[during the build, towards the end (docbook generation)]
$ free -m
total used free shared buffers cached
Mem: 7991 7830 160 0 57 6435
-/+ buffers/cache: 1338 6652
Swap: 0 0 0
$ time debuild -j8
[…]
real 142m17.038s
user 249m31.896s
sys 33m25.303s
The system remains responsive during the whole build time, video
display remains fluent.
*tmpfs*
single GPT partition spanning the whole disk, freshly mkswap'ed
benchmark /mnt tmpfs rw,nosuid,nodev,relatime,size=838860800k 0 0
[during the build, towards the end (docbook generation)]
$ free -m
total used free shared buffers cached
Mem: 7991 7486 504 0 2 6527
-/+ buffers/cache: 956 7034
Swap: 953868 7142 946726
[immediately after the build]
$ free -m
total used free shared buffers cached
Mem: 7991 7250 740 0 87 6302
-/+ buffers/cache: 861 7129
Swap: 953868 11846 942021
$ time debuild -j8
[…]
real 163m15.803s
user 253m6.583s
sys 35m38.599s
Once the system gets under memory pressure (more than ~7-9 GB space
needed on tmpfs), system responsiveness is gone. Video playback becomes
a strobe light slide show, mouse and cli are choppy, moving windows is
basically impossible - not enough to get tempted to hit hard-reset, but
interactive system use is no longer useful.
Of course this is not a representative benchmark, unless swap is
many times larger than system RAM, but it shows what happens when
tmpfs gets full (which is not an unlikely situation, as demonstrated
in this thread) and enforces swapping. Keep in mind that the OOM killer
cannot evict tmpfs, but only page it out. However comparable
situations might easily arise on systems up to 1 GB RAM and twice its
RAM size as swap, these systems have basically no RAM to spare for
tmpfs.
While I'm not arguing for or against the RAMTMP defaults, given that I
tend deviate from normal procedures[1] here, I don't think systems with
less than 2 GB system RAM can spare any of their RAM for /tmp/[2]. Even
on systems with more RAM, it might be pretty hard to reserve enough space
on a tmpfs backed /tmp/ to meet the expectations of contemporary
applications, without compromising on system memory.
Regards
Stefan Lippers-Hollmann
[1] by bind mounting /var/tmp/ on /tmp/, either backed by a
separate /var/ partition or a dedicated /var/tmp/ partition on
servers
[2] using KDE4 or GNOME3, anything below 1 GB RAM severely limits
"multi-tasking"; running browser, office suite, PDF viewer,
file manager at email client at once basically requires
~1.5 GB RAM at least.
Reply to: