I hesitate to prolong this thread further, but I do have a couple of data points. (and couldn't let Neil's nonsense go).
+++ Neil Williams [2012-05-25 16:15 +0100]: > > So instead of fixing the defaults you suggest everybody to drop the > > programs they use (mc, firefox, mysql)? ;) > > On machines which don't have the resources for those programs, yes. > There are alternatives out there - change to a less hungry program or > expand the hardware. The idea that there are machines without the resources for mc is silly. It's a very low-resource console-based program. But there is this issue of the way its vfs does temporay unpacking in /tmp. That makes sense in the 'this is temporary, it should go away on reboot' sense, but some big files will use up a lot of ram when /tmp is tmpfs. I don't know what the right thing to do about this is, but the 'set TMPDIR' sugestion is useless IMHO. When I start mc I have no idea what things will be unpacked under the VFS over the next days/weeks. I don't want _everything_ to go in /var/tmp and not get cleaned up automatically (is there cron job that does this for old files?) Perhaps mc should get clever and change TMPDIR itself on the fly for large files, but I don't know how practical that is. I only have 2G in this machine and astonishing slowdown due to thrashing is quite common after a few days work (generally firefoxes fault). I do begrudge /tmp (and thus tmpfs) having more than a few MB of ram. hmm. I just checked some stats: after looking inside a 45MB .deb files in mc: tmpfs 382M 212K 382M 1% /tmp so it's not unpacking it there any more even though MC_TMPDIR=/tmp/mc-wookey perhaps this issue is fixed at least for this app? here's a case where a lot of space gets used in there: open a .ppt (powerpoint) file in libreoffice. The conversion involves writing a file in /tmp/<mktmpdir> for every page/image. To open an image-heavy 256Mb .ppt I have lying about here, generates 382MB of files in /tmp. I tried to do this live when someone was having trouble with a presentation - it took over 20mins to open this file due to thrashing and I was unable to save the presenation from being something of a disaster. /tmp being a tmpfs presumably contributed to that failure (It just opened fine in about 2mins on the same machine with less memory pressure). And of course I didn't set 'TMPDIR' beforehand a) because all I did was double-click on the file in the filer, which ran libreoffice impress and b) because I had no idea that it would general hundreds of megs of files in /tmp. (I found out afterwards). So I'm with serge that this can be a real-world problem. I'm not claiming that the only solution is a real-disk /tmp, because I agree with those who do see advantages in /tmp as tmpfs so long as /tmp stays fairly small. > No problem with tmpfs being in RAM, it's all about being rational in > the selection of packages. 'firefox' is a perfectly rational choice of package on this laptop of 2G ram. mc is a rational choice on any machine. You can't solve the issue of 'unpacking huge tarballs/debs/whatevers' in /tmp' by telling people to use different packages. Something else is needed. It is possible that that something else already exists, but I must admit to now being a little confused about what actually happens as this thread contains conflicting info. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120526175935.ge11...@stoneboat.aleph1.co.uk
