FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 04-13-2011, 11:34 AM
"Bernhard R. Link"
 
Default Default size limits for /run (/var/run) and /run/lock (/var/lock)

* Philip Hands <phil@hands.com> [110413 12:54]:
> This strikes me as suboptimal, since one could use the disk space
> allocated to /tmp as extra swap and then allocate a tmpfs of that size
> to be mounted on /tmp with no effect other than allowing the system to
> have access to more swap than it would have otherwise had (of course,
> that's probably more than it needs, so instead you could just save some
> disk space that would otherwise be left generally unused by overloading
> the swap usage with /tmp usage.
>
> Therefore, in the multi-partition setup, I think we should also default
> to having /tmp on tmpfs.

This has both the disadvantage of a system then having swap (given the
big memory sizes one currently has and the big difference between RAM
and disk access times, having swap is often quite a disadvantage) and
of mixing several different things (/tmp is usually something simply
filling over time, so without low enough limits one risks that something
important is sometime not working because of missing RAM).

Bernhard R. Link


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110413113412.GA3881@pcpool00.mathematik.uni-freiburg.de">http://lists.debian.org/20110413113412.GA3881@pcpool00.mathematik.uni-freiburg.de
 
Old 04-13-2011, 03:27 PM
"Bernhard R. Link"
 
Default Default size limits for /run (/var/run) and /run/lock (/var/lock)

* Philip Hands <phil@hands.com> [110413 15:51]:
> Are you suggesting that a system that has enough RAM to not need swap
> will become slower if you enable swap but don't use it?

If you don't use it it will hopefully make not much big difference.
The difference is if it gets used. If some program goes harvoc and
allocates to much stuff without swap it will most of the time simply
get killed. With swap it will first make the computer unuseably slow
for some time before it finally gets killed.

> > of mixing several different things (/tmp is usually something simply
> > filling over time,
>
> Really? Checking a couple of servers at random, one that's been running
> for about 8 months but is fairly tightly locked down, has 8Kb used,

Servers of course usually have not that much (unless they are
terminal/login servers). The big /tmp stuff are usually user programs and
lab computers and other machines with many different users loging in are usually
multi-partition.

Some lab computers:
/dev/sda7 6,5G 164M 6,0G 3% /tmp
/dev/sda7 6,5G 157M 6,0G 3% /tmp
/dev/sda7 6,5G 148M 6,0G 3% /tmp
/dev/sda7 6,5G 145M 6,0G 3% /tmp
/dev/sda7 6,5G 205M 5,9G 4% /tmp
/dev/sda7 6,5G 321M 5,8G 6% /tmp
/dev/sda7 6,5G 148M 6,0G 3% /tmp
/dev/sda7 6,5G 225M 5,9G 4% /tmp
/dev/sda7 6,5G 2,8G 3,4G 46% /tmp
/dev/sda7 6,5G 152M 6,0G 3% /tmp
/dev/sda7 6,5G 152M 6,0G 3% /tmp
/dev/sda7 6,5G 150M 6,0G 3% /tmp
/dev/sda7 6.5G 162M 6.0G 3% /tmp

A login server:
/dev/vda4 21G 173M 18G 1% /tmp

A login server from another institute:
/dev/hda5 9,9G 1,2G 8,2G 13% /tmp

> If you'd read what I wrote, I suggested that a reasonable start would be
> to allocate the /tmp filesystem space as swap, and then limit /tmp to
> that size -- even if you then fill /tmp it cannot exceed the extra size
> that you allocated to swap by giving it the disk that you'd otherwise be
> using for /tmp as a file system.

And how do you make sure those metrics are correct if that is enabled
as default in the installer?

> In fact, it wouldn't surprise me if the act of mounting an additional
> filesystem consumes more memory than a tmpfs with 8kb of files on it, so
> for the first server mentioned above I may well be consuming less RAM
> than I would be mounting an empty /tmp from the disk.

RAM is nowadays for most uses usually there in abundancy. It's not that
it is scarce. The problems are faulty programs trying to get as much as
they can. If things grow unlimited there will always hit the limit.
And having different limits usually makes things more easy to control.

Bernhard R. Link


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110413152716.GA5014@pcpool00.mathematik.uni-freiburg.de">http://lists.debian.org/20110413152716.GA5014@pcpool00.mathematik.uni-freiburg.de
 

Thread Tools




All times are GMT. The time now is 10:17 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org