From: Johannes Weiner <hannes@cmpxchg.org>
To: Serge Hallyn <serge.hallyn@ubuntu.com>
Cc: Aaron Staley <aaron@picloud.com>,
containers@lists.linux-foundation.org,
Paul Menage <menage@google.com>, Li Zefan <lizf@cn.fujitsu.com>,
Michal Hocko <mhocko@suse.cz>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: PROBLEM: Processes writing large files in memory-limited LXC container are killed by OOM
Date: Mon, 1 Jul 2013 14:45:03 -0400 [thread overview]
Message-ID: <20130701184503.GG17812@cmpxchg.org> (raw)
In-Reply-To: <20130701180101.GA5460@ac100>
On Mon, Jul 01, 2013 at 01:01:01PM -0500, Serge Hallyn wrote:
> Quoting Aaron Staley (aaron@picloud.com):
> > This is better explained here:
> > http://serverfault.com/questions/516074/why-are-applications-in-a-memory-limited-lxc-container-writing-large-files-to-di
> > (The
> > highest-voted answer believes this to be a kernel bug.)
>
> Hi,
>
> in irc it has been suggested that indeed the kernel should be slowing
> down new page creates while waiting for old page cache entries to be
> written out to disk, rather than ooming.
>
> With a 3.0.27-1-ac100 kernel, doing dd if=/dev/zero of=xxx bs=1M
> count=100 is immediately killed. In contrast, doing the same from a
> 3.0.8 kernel did the right thing for me. But I did reproduce your
> experiment below on ec2 with the same result.
>
> So, cc:ing linux-mm in the hopes someone can tell us whether this
> is expected behavior, known mis-behavior, or an unknown bug.
It's a known issue that was fixed/improved in e62e384 'memcg: prevent
OOM with too many dirty pages', included in 3.6+.
> > Summary: I have set up a system where I am using LXC to create multiple
> > virtualized containers on my system with limited resources. Unfortunately, I'm
> > running into a troublesome scenario where the OOM killer is hard killing
> > processes in my LXC container when I write a file with size exceeding the
> > memory limitation (set to 300MB). There appears to be some issue with the
> > file buffering respecting the containers memory limit.
> >
> >
> > Reproducing:
> >
> > /done on a c1.xlarge instance running on Amazon EC2
> >
> > Create 6 empty lxc containers (in my case I did lxc-create -n testcon -t
> > ubuntu -- -r precise)
> >
> > Modify the configuration of each container to set lxc.cgroup.memory.
> > limit_in_bytes = 300M
> >
> > Within each container run:
> > dd if=/dev/zero of=test2 bs=100k count=5010
> > parallel
> >
> > This will with high probability activate the OOM (as seen in demsg); often
> > the dd processes themselves will be killed.
> >
> > This has been verified to have problems on:
> > Linux 3.8.0-25-generic #37-Ubuntu SMP and Linux ip-10-8-139-98
> > 3.2.0-29-virtual #46-Ubuntu SMP Fri Jul 27 17:23:50 UTC 2012 x86_64 x86_64
> > x86_64 GNU/Linux
> >
> > Please let me know your thoughts.
> >
> > Regards,
> > Aaron Staley
> > _______________________________________________
> > Containers mailing list
> > Containers@lists.linux-foundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/containers
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Johannes Weiner <hannes@cmpxchg.org>
To: Serge Hallyn <serge.hallyn@ubuntu.com>
Cc: Aaron Staley <aaron@picloud.com>,
containers@lists.linux-foundation.org,
Paul Menage <menage@google.com>, Li Zefan <lizf@cn.fujitsu.com>,
Michal Hocko <mhocko@suse.cz>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: PROBLEM: Processes writing large files in memory-limited LXC container are killed by OOM
Date: Mon, 1 Jul 2013 14:45:03 -0400 [thread overview]
Message-ID: <20130701184503.GG17812@cmpxchg.org> (raw)
In-Reply-To: <20130701180101.GA5460@ac100>
On Mon, Jul 01, 2013 at 01:01:01PM -0500, Serge Hallyn wrote:
> Quoting Aaron Staley (aaron@picloud.com):
> > This is better explained here:
> > http://serverfault.com/questions/516074/why-are-applications-in-a-memory-limited-lxc-container-writing-large-files-to-di
> > (The
> > highest-voted answer believes this to be a kernel bug.)
>
> Hi,
>
> in irc it has been suggested that indeed the kernel should be slowing
> down new page creates while waiting for old page cache entries to be
> written out to disk, rather than ooming.
>
> With a 3.0.27-1-ac100 kernel, doing dd if=/dev/zero of=xxx bs=1M
> count=100 is immediately killed. In contrast, doing the same from a
> 3.0.8 kernel did the right thing for me. But I did reproduce your
> experiment below on ec2 with the same result.
>
> So, cc:ing linux-mm in the hopes someone can tell us whether this
> is expected behavior, known mis-behavior, or an unknown bug.
It's a known issue that was fixed/improved in e62e384 'memcg: prevent
OOM with too many dirty pages', included in 3.6+.
> > Summary: I have set up a system where I am using LXC to create multiple
> > virtualized containers on my system with limited resources. Unfortunately, I'm
> > running into a troublesome scenario where the OOM killer is hard killing
> > processes in my LXC container when I write a file with size exceeding the
> > memory limitation (set to 300MB). There appears to be some issue with the
> > file buffering respecting the containers memory limit.
> >
> >
> > Reproducing:
> >
> > /done on a c1.xlarge instance running on Amazon EC2
> >
> > Create 6 empty lxc containers (in my case I did lxc-create -n testcon -t
> > ubuntu -- -r precise)
> >
> > Modify the configuration of each container to set lxc.cgroup.memory.
> > limit_in_bytes = 300M
> >
> > Within each container run:
> > dd if=/dev/zero of=test2 bs=100k count=5010
> > parallel
> >
> > This will with high probability activate the OOM (as seen in demsg); often
> > the dd processes themselves will be killed.
> >
> > This has been verified to have problems on:
> > Linux 3.8.0-25-generic #37-Ubuntu SMP and Linux ip-10-8-139-98
> > 3.2.0-29-virtual #46-Ubuntu SMP Fri Jul 27 17:23:50 UTC 2012 x86_64 x86_64
> > x86_64 GNU/Linux
> >
> > Please let me know your thoughts.
> >
> > Regards,
> > Aaron Staley
> > _______________________________________________
> > Containers mailing list
> > Containers@lists.linux-foundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/containers
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2013-07-01 18:45 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-25 5:45 PROBLEM: Processes writing large files in memory-limited LXC container are killed by OOM Aaron Staley
[not found] ` <CAMcjixYa-mjo5TrxmtBkr0MOf+8r_iSeW5MF4c8nJKdp5m+RPA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-06-25 13:24 ` Serge Hallyn
2013-06-25 20:54 ` Aaron Staley
[not found] ` <CAMcjixZtW0KdAmLXyDoGFqL2qh4aEgdGjBYJWrPESFMz0dvELw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-06-27 5:12 ` Zhu Yanhai
[not found] ` <CAC8teKXNof5PdU2dMz4iZ8tM=Dx=aZ0efxotDhdc-xopeK-+Xg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-06-27 5:19 ` Aaron Staley
[not found] ` <CAMcjixZdXWGezcVQPPo3M0yNBx4TtbiOoqYJQWvNbTyqULifUA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-06-27 20:51 ` Aristeu Rozanski
2013-07-01 15:21 ` Serge Hallyn
2013-07-01 15:27 ` Aaron Staley
2013-06-28 18:52 ` Serge E. Hallyn
2013-07-01 18:01 ` Serge Hallyn
2013-07-01 18:01 ` Serge Hallyn
2013-07-01 18:01 ` Serge Hallyn
2013-07-01 18:45 ` Johannes Weiner
2013-07-01 18:45 ` Johannes Weiner [this message]
2013-07-01 18:45 ` Johannes Weiner
2013-07-01 18:51 ` Aaron Staley
[not found] ` <20130701184503.GG17812-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2013-07-01 18:51 ` Aaron Staley
2013-07-01 19:02 ` Serge Hallyn
2013-07-01 19:02 ` Serge Hallyn
2013-07-01 19:02 ` Serge Hallyn
2013-07-02 12:42 ` Michal Hocko
2013-07-02 12:42 ` Michal Hocko
2013-07-02 12:42 ` Michal Hocko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130701184503.GG17812@cmpxchg.org \
--to=hannes@cmpxchg.org \
--cc=aaron@picloud.com \
--cc=containers@lists.linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lizf@cn.fujitsu.com \
--cc=menage@google.com \
--cc=mhocko@suse.cz \
--cc=serge.hallyn@ubuntu.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.