/tmp uses 8 Gb, that is half of my RAM. Then my RAM is fully occupied as soon as I open Plasma+Firefox+Thunderbird. But /tmp is used at 1% only. Can I reduce it to 4Gb? I do not see any entry in /etc/fstab (have F24). Thanks,
Frédéric
On 11/18/16 21:10, Frédéric Bron wrote:
/tmp uses 8 Gb, that is half of my RAM. Then my RAM is fully occupied as soon as I open Plasma+Firefox+Thunderbird. But /tmp is used at 1% only. Can I reduce it to 4Gb? I do not see any entry in /etc/fstab (have F24).
This really shouldn't be much of an issue.
While tmpfs does utilize RAM it will actually move contents to swap in the event RAM is actually needed.
If you're really concerned about tmpfs you can always force it to use real disk by doing a
systemctl mask tmp.mount
and rebooting. You can then choose to keep /tmp in / or mount another partition via an fstab entry.
While tmpfs does utilize RAM it will actually move contents to swap in the event RAM is actually needed.
So that's normal that my RAM looks full (in top) and the swap and /tmp are empty. This means that I still have about 8Gb free RAM available, right? I am happy then. Thanks, Frédéric
On 11/18/2016 07:39 AM, Frédéric Bron wrote:
While tmpfs does utilize RAM it will actually move contents to swap in the event RAM is actually needed.
So that's normal that my RAM looks full (in top) and the swap and /tmp are empty. This means that I still have about 8Gb free RAM available, right? I am happy then.
You have all 16GB available. That "8GB" for /tmp is just a limit. The actual space used grows and shrinks as you add and delete files there. Think of it like the ulimit for process size. Just because processes might be allowed to grow to 4GB doesn't mean that all processes _use_ 4GB.
There really isn't a lot of difference between /tmp in RAM and /tmp on disk.
With /tmp on disk, files are written initially to the buffer cache, and get flushed out to disk when something else needs the RAM or, eventually, by the automatic push of dirty buffer pages. For the latter case, a copy of the data remains in the buffer until something else needs that RAM. Short-lived files might spend their entire lives in the buffer and never get pushed out to disk.
With /tmp in RAM, files get written to the RAM pages and get pushed out to swap when something else needs the RAM.
The only difference is whether longer-lived files always get written to disk regardless of the memory load.
As for RAM appearing full, see http://www.linuxatemyram.com/.
On 11/18/2016 06:30 AM, Robert Nichols wrote:
On 11/18/2016 07:39 AM, Frédéric Bron wrote:
While tmpfs does utilize RAM it will actually move contents to swap in the event RAM is actually needed.
So that's normal that my RAM looks full (in top) and the swap and /tmp are empty. This means that I still have about 8Gb free RAM available, right? I am happy then.
You have all 16GB available. That "8GB" for /tmp is just a limit. The actual space used grows and shrinks as you add and delete files there. Think of it like the ulimit for process size. Just because processes might be allowed to grow to 4GB doesn't mean that all processes _use_ 4GB.
There really isn't a lot of difference between /tmp in RAM and /tmp on disk.
With /tmp on disk, files are written initially to the buffer cache, and get flushed out to disk when something else needs the RAM or, eventually, by the automatic push of dirty buffer pages. For the latter case, a copy of the data remains in the buffer until something else needs that RAM. Short-lived files might spend their entire lives in the buffer and never get pushed out to disk.
With /tmp in RAM, files get written to the RAM pages and get pushed out to swap when something else needs the RAM.
The only difference is whether longer-lived files always get written to disk regardless of the memory load.
As for RAM appearing full, see http://www.linuxatemyram.com/.
The main problem for using a RAMdisk-based /tmp is that a hell of a lot of utilities still write temp files to /tmp and with its limited size, you often get "filesystem full" errors.
Before you start on me, I know the new guidelines say for "large" temp files the program is supposed to use /var/tmp, but the VAST majority do NOT do that and probably never will. I live in the real world, solving real problems and the first thing I do is mask tmp.mount on any installation. I'm somewhat surprised that they actually gave us a relatively easy way to get around this stupid idea. I wish it were as easy to sh*tcan systemd and journalctl (two other really moronic, overly complicated and badly implemented ideas). ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - When all else fails, try reading the instructions. - ----------------------------------------------------------------------
On 11/18/2016 12:04 PM, Rick Stevens wrote:
The main problem for using a RAMdisk-based /tmp is that a hell of a lot of utilities still write temp files to /tmp and with its limited size, you often get "filesystem full" errors.
Before you start on me,...
Oh, no disagreement there. I come from a background of a small root filesystem with a correspondingly small /tmp, and everything else (/usr, /var, /home, ...) separate. So it's pretty much a "same old, same old" issue for me. Heck, even a 2GB /tmp is way bigger than what I'm used to running with.
On 11/18/2016 10:04 AM, Rick Stevens wrote:
installation. I'm somewhat surprised that they actually gave us a relatively easy way to get around this stupid idea. I wish it were as easy to sh*tcan systemd and journalctl (two other really moronic, overly complicated and badly implemented ideas).
Please keep your unnecessary ranting off the list. Most (all?) of the major Linux distributions have switched to using systemd for clear reasons. You are in a very small (but excessively vocal) minority that dislikes it for unknown reasons. As a user and system administrator of many computers, I am very happy to be using systemd now. It makes most things much easier. And journalctl as well. Log files with metadata included? Very helpful.
On 11/18/2016 03:13 PM, Samuel Sieb wrote:
On 11/18/2016 10:04 AM, Rick Stevens wrote:
installation. I'm somewhat surprised that they actually gave us a relatively easy way to get around this stupid idea. I wish it were as easy to sh*tcan systemd and journalctl (two other really moronic, overly complicated and badly implemented ideas).
Please keep your unnecessary ranting off the list. Most (all?) of the major Linux distributions have switched to using systemd for clear reasons. You are in a very small (but excessively vocal) minority that dislikes it for unknown reasons. As a user and system administrator of many computers, I am very happy to be using systemd now. It makes most things much easier. And journalctl as well. Log files with metadata included? Very helpful.
What can I say? You are entitled to your opinions, as am I. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - To understand recursion, you must first understand recursion. - ----------------------------------------------------------------------
Allegedly, on or about 18 November 2016, Robert Nichols sent:
With /tmp on disk, files are written initially to the buffer cache, and get flushed out to disk when something else needs the RAM or, eventually, by the automatic push of dirty buffer pages. For the latter case, a copy of the data remains in the buffer until something else needs that RAM. Short-lived files might spend their entire lives in the buffer and never get pushed out to disk.
With /tmp in RAM, files get written to the RAM pages and get pushed out to swap when something else needs the RAM.
For a number of years, I'd found that temporary files in /tmp (on disc) did not get automatically removed, when they should do (programs that created them didn't erase them, and the regular purge cron job doesn't remove them). The regular purge cron job is supposed to remove old files ("old" by a finite number of days), that haven't been *recently* accessed nor created, so that they don't remove something that may still be needed, but do automatically remove cruft (cruft that programs really should have removed by themselves).
To try and resolve that I make sure that I don't browse into /tmp with programs like Nautilus, and I have gone through *other* configs to make sure that the /tmp directory doesn't get scanned by indexers (so *nothing* should be accessing them to make them appear still needed). I can even reboot, so there should be no programs still holding onto those files. Yet, I'll still find files that are very old.
Admittedly, I haven't been keeping a close eye on this with the computers with the newest installations, but the issue had always been there whenever I looked. I have an old file server still running, that has some tmp files going back to 2006 (e.g. "mapping-<username>" and "OSL_PIPE_500_SingleOfficeIPC_<hash>").
But it's that kind of behaviour that makes me loathe to have a RAM-based /tmp, as it'd just fill up unless I rebooted or manually deleted things.
-
Ed Greshko -
Frédéric Bron -
Rick Stevens -
Robert Nichols -
Samuel Sieb -
Tim