On Tue, Apr 22, 2014 at 8:21 PM, Herbert Poetzl <herbert@13thfloor.at> wrote:
> On Tue, Apr 22, 2014 at 02:15:27PM +0700, Sergiusz Pawlowicz wrote:
>> On Tue, Apr 22, 2014 at 2:05 PM, Urban Loesch <bind@enas.net> wrote:
>
>>> For me the only solution now is to give the guest enough
>>> memory so that it can't reach the limits.
>
>>> From my experience, on 3.4x line cgroups are able to enforce limits,
>
>> on later kernels whole server hangs. But sticking to 3.4x is
>> not a long term solution.
>
>> If the issue won't get resolved, unfortunately it means we will
>> have to escape from linux-vserver to KVM, where cgroups work
>> properly :-(
>
> We do not modify the mainline cgroup system, so it is the same
> system whether you use it for Linux-VServer or KVM, which in
> turn means, if it is broken in one of the upstream kernels
> (and it looks like it has some issues in certain kernel versions)
> it will be broken for Linux-VServer (and KVM) as well.
Hi Herbert,
no, KVM, which I have tested, is not taking down the whole server. It
OOMs and kills the process which is taking the memory.
I'm not sure if anything is "broken", it seems vserver way of
implementing cgroup limits is not intelligent enough. From my
understanding, and previous attempts to explain the issue I could read
on the mailing list, if vserver guest is OOMing, cgroup enforces
complete blockade not only on the RAM, but also of the filesystem,
which in consequence blocks the whole server, which hangs.
It is major issue, which must be investigated (and is easy to
simulate) or vserver technology will be outdated.
S.
Received on Tue Apr 22 14:35:30 2014