On Mon, 2005-12-12 at 18:41 +0100, Herbert Poetzl wrote:
> On Mon, Dec 12, 2005 at 07:34:01PM +0200, Roché Compaan wrote:
> > On Mon, 2005-12-12 at 18:19 +0100, Herbert Poetzl wrote:
> > > On Mon, Dec 12, 2005 at 07:13:46PM +0200, Roché Compaan wrote:
> > > > On Mon, 2005-12-12 at 16:53 +0100, Herbert Poetzl wrote:
> > > > > On Mon, Dec 12, 2005 at 03:34:13PM +0200, Roché Compaan wrote:
> > > > > > On Mon, 2005-12-12 at 03:06 +0100, Herbert Poetzl wrote:
> > > > > > > On Sun, Dec 11, 2005 at 10:28:04PM +0200, Roché Compaan wrote:
> > > > > > > > On Sun, 2005-12-11 at 11:34 -0800, Alexander Kabanov wrote:
> > > > > > > > > hi,
> > > > > > > > >
> > > > > > > > > i'm having similar errors (I do have limits and scheduler set, using
> > > > > > > > > rlimits (as, rss, nproc) and scheduler) whenever i do stress testing,
> > > > > > > > > (overloading mta or web server for example).
> > > > > > > > >
> > > > > > > > > during a stress test, some applications die because of no memory
> > > > > > > > > available or can't fork, some stop with segmentation fault (not able
> > > > > > > > > to do vserver <vs> enter),. when attacking httpd might have httpd
> > > > > > > > > <defunct>.
> > > > > > > >
> > > > > > > > I am experiencing the same problems. The segfaults and not being able to
> > > > > > > > enter a vserver from the host *really* worries me.
> > > > > > >
> > > > > > > well, if the limits are reached, the guest can not create
> > > > > > > new processes and/or instantiate more memory ... of course
> > > > > > > this might lead to program termination and the fact that
> > > > > > > a guest cannot be entered (as the limits are hard limits).
> > > > > > > raising them will make it all work again ...
> > > > > >
> > > > > > If the vserver is hitting the limit then I'm less worried because I
> > > > > > can solve the problem by increasing the limit. I misread and thought
> > > > > > that there was plenty of memory to spare.
> > > > > >
> > > > > > Would I be right in assuming that increasing only the virtual memory
> > > > > > will solve the problem?
> > > > >
> > > > > probably that will solve 80% of the issues
> > > > > (see VM vs RSS hit ratio)
> > > >
> > > > Where?
> > >
> > > in the original email you sent (you removed the
> > > lines so I could not refer to them ...)
> >
> > Ah, thanks.
> >
> > >
> > > > > > I don't mind if virtual servers use swap space if they need memory
> > > > > > because we have plenty of disk space, but I don't want them to
> > > > > > consume all the physical memory on the box.
> > > > >
> > > > > trust me, you do mind as soon as the guests start
> > > > > swapping in and out ...
> > > >
> > > > Sorry, you'll have to explain - I don't understand how the vserver or
> > > > the linux kernel manages virtual memory or what you mean when you say
> > > > "swapping in and out".
> > >
> > > consider a total of 256 MB memory (RAM) on the host
> > > further, consider three guests with a memory footprint
> > > of 128MB RSS (means they need to have 128MB in memory
> > > to run, that's what Resident Set Size is), now they
> > > are alternating and will constantly swap in and out
> > > memory, because 3*128 > 256 ...
> >
> > But what if I limit the sum of virtual server RSS limits to never
> > exceed the total RAM on the host as a rule, and make sure that there
> > is enough virtual memory for all of them? Ie. I have 4 GB RAM on
> > the host and 4 vservers that each have a hard limit of 1 GB RSS and
> > say triple the virtual memory. Would I still get memory errors when
> > vservers reach the RSS limit, or only when they reach the VM limit?
>
> assumed that the guests use the RSS equally, you
> will not get any over RSS limit hits, as the pages
> will be swapped out when (or slightly before) they
> reach the limit (but in reality, one or the other
> guest will try to use slightlly more and will hit
> the hard limit ...)
It seems like the most responsible thing to do now is to abandon hard
limits (and wait for soft limits) and babysit vservers in the mean time.
Processes that take up to match memory can then either be restarted or
killed manually, rather than allowing the kernel to make that decision.
-- Roché Compaan Upfront Systems http://www.upfrontsystems.co.za _______________________________________________ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserverReceived on Tue Dec 13 15:44:07 2005