From: Matt Ayres (matta_at_tektonic.net)
Date: Mon 17 Nov 2003 - 18:09:12 GMT
Mark,
You're correct, we observed the same thing. The CPU/Load is caused by
kswapd. Errors exactly like this has been reported for 2.4.2 and 2.4.9
(that we can find), so perhaps one of the bugs re-surfaced in 2.4.2X.
We've tried this with and without Herbert's rmap15k patches. Slightly
different behavior is observed, but the end result is the same.
I've just got finished a working port of vserver under UML (very cool!).
Herbert is going to look it over/redo it and then I don't see why it
wouldn't be released.
I'm going to try to split up the load under multiple UML's (ie. 4-8
vservers per UML instance) and then I can get full console (with
sysrq!).
On Mon, 2003-11-17 at 13:00, Mark Lawrence wrote:
> Hi Matt,
>
> On Mon, 17 Nov 2003, Matt Ayres wrote:
> > I have 2 servers who keep crashing, sometimes every few hours... I am
> > still working on a console solution so I don't know the exact place
> > where the problem is.
>
> I can perhaps provide a little bit of information with regards to this,
> since I am hosted on one of those machines :)
>
> You will see from the attached graph, that a symptom (although probably
> not the cause) of each hang is a continual descreasing of free and
> unbuffered memory. Swap seems to be untouched.
>
> I have also seen an increase of the cpu (up to 60-70%) used for "system"
> tasks right before each hang. I bet if you extrapolate the current usage
> you could reasonably predict the next hang... which at least make the
> problem reproducable :)
>
> So it seems as if something in the virtual memory system is killing the
> box, although how the vserver patch affect this I don't know because I
> didn't think we actually touched the vm code.
>
> I would theorize that tcp connects are established ok, but that the first
> thing to happen in most cases is to grab some free memory which doesn't
> exist. Perhaps there is then some thrashing before things come to a
> complete halt.
>
> Does anyone know what the normal kernel behaviour is with regards to
> releasing cached/buffered memory in order to keep some free? What else
> could cause this type of behaviour?
>
> Cheers, Mark.
> --
> Mark Lawrence (nomad_at_null.net)
-- Matt Ayres <matta_at_tektonic.net> TekTonic_______________________________________________ Vserver mailing list Vserver_at_list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver