About this list Date view Thread view Subject view Author view Attachment view

From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Fri 26 Aug 2005 - 00:13:09 BST

On Thu, Aug 25, 2005 at 10:43:42PM +0200, Werner Schalk wrote:
> Hi,
> again because I didn't understand it:
> How can I give each of my vservers a maximum RAM
> limit of 64 MB?

the same way, you can configure a 200MHz CPU for them ...

not at all, there is no such thing!

lets take a step back and think about the way linux-vserver
works .. you probably read about the single kernel and
isolation stuff, as well as (maybe) the benefits you get
by sharing resources and such things ...

let's assume, there is no resource sharing at all, and
inode/dentry (filesystem) caches and process structures
just wouldn't be used, no swapping, no caching at all

in this case, we still would have a hard time to change
the very advanced page handling code in the kernel to
use just a certain amount/area of your RAM, and it would
even get worse if you wanted to change the 'reserved'
amount of RAM (i.e. make it larger or smaller) ...

now let's add back all that fancy stuff like swapping,
filesystem caches, shared binaries and memory mapped
files, accessed by partially overlapping threads of a
single server application ...

you probably can imagine that we would lose a lot of the
resource sharing benefits and basically convert this
project into something else (like UML or Xen) with a
separate kernel, no shared stuff and such, just to get
the 64MB of RAM you would like to see so much :)

now to get back to the original questioni (or what it
should have been), how to limit memory resources for your
guests ...

first, we currently allow limits for three different
memory apsects and accounting for two more, which might
get limits soon.

the first one is VM (or AS) which means Virtual Memory
(or Address Space), which is some kind of upper limit
a process can request. this is available per process via
the ulimits and per context (via rlimits) which actually
is just a sum over all processes/threads.

this limit includes all different kinds of memory at
basically all levels, so it includes file mappings as
well as swapped out pages, pages locked into memory and
those typical 'RAM' stuff ...

the second one is RSS, which is short for Resident Set
Size, and means the pages actually in RAM, consuming the
precious resources ...

(just for the sake of completeness, the others are VML
or Locked Memory, Anonymous Memory and Shared Memory)

so why not simply set RSS to 64MB and be done?

well, you can certainly do that, and I guess most apps
will handle that perfectly well, unfortunately there
are certain apps which tend to allocate huge amounts
of virtual memory, just in case they'll need it later
on, and those will be really suprised, once they reach
the RSS limit and get killed off by the OOM killer.

also, it's not easy to account shared resources properly
who will pay for that cached file? the first one?
everyone? what happens if one of two 'sharing' contexts
is removed?

so my advice here is simple: you can get a pretty good
idea how much memory resources your specific guest uses
and used to use by looking at the information stored in
/proc/virtual/*/limits ...

try to keep the RSS around 1.5 times the observed maximum
(of a guest running within parameters) and the VM around
2-4 times, of course, you can adjust and/or weight those
limits according to your resource policy

In case you were just looking for the files, they are
in /etc/vservers/<name>/rlimits/{rss,as}, and in case
you wanted to know the units, they are pages (which have
a size of 4k on x86)



> Thanks and bye,
> Werner
> _______________________________________________
> Vserver mailing list
> Vserver_at_list.linux-vserver.org
> http://list.linux-vserver.org/mailman/listinfo/vserver
Vserver mailing list

About this list Date view Thread view Subject view Author view Attachment view
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Fri 26 Aug 2005 - 00:13:41 BST by hypermail 2.1.3