linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Russell Coker <russell@coker.com.au>
To: Marc MERLIN <marc@merlins.org>
Cc: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>,
	linux-btrfs@vger.kernel.org
Subject: Re: Is btrfs related to OOM death problems on my 8GB server with both 3.15.1 and 3.14?
Date: Sat, 05 Jul 2014 00:45:55 +1000	[thread overview]
Message-ID: <3262371.bchVJ2xl3c@xev> (raw)
In-Reply-To: <20140704142416.GI26932@merlins.org>

On Fri, 4 Jul 2014 07:24:16 Marc MERLIN wrote:
> On Fri, Jul 04, 2014 at 03:23:41PM +0900, Satoru Takeuchi wrote:
> > >Is there any correlation between such problems and BTRFS operations such
> > >as
> > >creating snapshots or running a scrub/balance?
> > 
> > Were you running scrub, Marc?
> 
> Yes, I was due to the other problem I was discussing on the list. I
> wanted to know if scrub would find any problem (it did not).
> I think I'll now try to read every file of every filesystem to see what
> btrfs does (this will take a while, that's around 100 million files).
> 
> But the last times I had this OOM problem with 3.15.1 it was happening
> within 6 hours sometimes, and I was not starting scrub every time the
> system booted, so scrub may be partially responsible but it's not the
> core problem.

It would be a good idea to run a few scrubs and see if this is a repeatable 
problem.  If it's a repeatable problem then it's something to fix regardless 
of whether it's the only issue you have.

> > Marc, do you change
> > 
> >  - software and its setting,
> >  - operations,
> >  - hardware configuration,
> > 
> > or any other, just before detecting first OOM?
> 
> Those are 3 good questions, I asked myself the same thing.
> From what I remember though all I did was going from 3.14 to 3.15.
> However this machine has many cronjobs, it does rsyncs to and from
> remote systems, it has btrfs send/receive going to and from it, and
> snapshots every hour.
> Those are not new, but if any of them changed in a small way, I guess
> they could trigger bugs.

If a scrub can reliably trigger the problem it would be good to test 3.14 for 
the same behavior.  Knowing whether it's a regression would help the 
developers.

> > You have 8GB RAM and there is plenty of swap space.
> 
> Correct.

Even without much swap 8G should be a plenty.  My main workstation has 4G of 
RAM and 6G of swap.  I almost never use more than 3G of swap because the 
system becomes so slow as to be almost unusable when swap gets to 4G (Chromium 
is to blame).  However that is for a 120G non-RAID filesystem.  Presumably a 
RAID array will need some more kernel memory and a larger filesystem will also 
need a little more, but it still shouldn't be that much.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/


  reply	other threads:[~2014-07-04 14:45 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-04  1:19 Is btrfs related to OOM death problems on my 8GB server with both 3.15.1 and 3.14? Marc MERLIN
2014-07-04  4:33 ` Russell Coker
2014-07-04  6:04   ` Marc MERLIN
2014-07-04  6:23   ` Satoru Takeuchi
2014-07-04 14:24     ` Marc MERLIN
2014-07-04 14:45       ` Russell Coker [this message]
2014-07-04 15:07         ` Marc MERLIN
2014-07-04 22:13       ` Duncan
2014-07-05 13:47 ` Andrew E. Mileski
2014-07-05 14:43   ` Marc MERLIN
2014-07-05 15:17     ` Andrew E. Mileski
2014-07-06 14:58     ` Marc MERLIN
2014-07-13 14:29       ` btrfs is " Marc MERLIN
2014-07-13 15:37         ` Marc MERLIN
2014-07-13 15:45           ` btrfs quotas " Marc MERLIN
2014-07-14  1:36             ` Qu Wenruo
2014-07-14  2:43               ` Marc MERLIN
2014-07-14  1:24         ` btrfs is " Qu Wenruo
2014-07-16  0:36           ` Jérôme Poulin
2014-07-16 15:55           ` Marc MERLIN
2014-07-17  2:22             ` Marc MERLIN
2014-07-16  0:45       ` Is btrfs " Jérôme Poulin
2014-07-05 14:27 ` Andrew E. Mileski

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=3262371.bchVJ2xl3c@xev \
    --to=russell@coker.com.au \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=marc@merlins.org \
    --cc=takeuchi_satoru@jp.fujitsu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).