From: Marc MERLIN <marc@merlins.org>
To: "Andrew E. Mileski" <andrewm@isoar.ca>
Cc: 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: Sun, 6 Jul 2014 07:58:15 -0700 [thread overview]
Message-ID: <20140706145815.GD15009@merlins.org> (raw)
In-Reply-To: <20140705144318.GT26932@merlins.org>
On Sat, Jul 05, 2014 at 07:43:18AM -0700, Marc MERLIN wrote:
> On Sat, Jul 05, 2014 at 09:47:09AM -0400, Andrew E. Mileski wrote:
> > On 2014-07-03 9:19 PM, Marc MERLIN wrote:
> > >I upgraded my server from 3.14 to 3.15.1 last week, and since then it's been
> > >running out of memory and deadlocking (panic= doesn't even work).
> > >I downgraded back to 3.14, but I already had the problem once since then.
> >
> > I didn't see any mention of the btrfs utility version in this thread
> > (I may be blind though).
> >
> > My server was suffering from frequent panics upon scrub / defrag /
> > balance, until I updated the btrfs utility. That resolved all my
> > issues.
>
> Really? The userland tool should only send ioctls to the kernel, I
> really can't see how it would cause the kernel code to panic or not.
>
> gargamel:~# btrfs --version
> Btrfs v3.14.1
> which is the latest in debian unstable.
>
> As an update, after 1.7 days of scrubbing, the system has started
> getting sluggish, I'm getting synchronization problems/crashes in some of
> my tools that talk to serial ports (likely due to mini deadlocks in the
> kernel), and I'm now getting a few btrfs hangs.
Predictably, it died yesterday afternoon after going into memory death
(it was answering pings, but userspace was dead, and even sysrq-o did
not respond, I had to power cycle the power outlet).
This happened just before my 3rd scrub finished, so I'm now 2 out of 2:
running scrub on my 3 filesystems kills the system half way through the
3rd scrub.
This is the last memory log that reached the disk:
http://marc.merlins.org/tmp/btrfs-oom2.txt
Do those logs point to any possible culprit, or a kernel memory leak
cannot be pointed to its source because the kernel loses track of who
requested the memory that leaked?
Excerpt here:
Sat Jul 5 14:25:04 PDT 2014
total used free shared buffers cached
Mem: 7894792 7712384 182408 0 28 227480
-/+ buffers/cache: 7484876 409916
Swap: 15616764 463732 15153032
Userspace is using 345MB according to ps
Sat Jul 5 14:25:04 PDT 2014
MemTotal: 7894792 kB
MemFree: 184556 kB
MemAvailable: 269568 kB
Buffers: 28 kB
Cached: 228164 kB
SwapCached: 18296 kB
Active: 178196 kB
Inactive: 187016 kB
Active(anon): 70068 kB
Inactive(anon): 71100 kB
Active(file): 108128 kB
Inactive(file): 115916 kB
Unevictable: 5624 kB
Mlocked: 5624 kB
SwapTotal: 15616764 kB
SwapFree: 15152768 kB
Dirty: 17716 kB
Writeback: 516 kB
AnonPages: 140588 kB
Mapped: 21940 kB
Shmem: 688 kB
Slab: 181708 kB
SReclaimable: 59808 kB
SUnreclaim: 121900 kB
KernelStack: 4728 kB
PageTables: 8480 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 19564160 kB
Committed_AS: 1633204 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 358996 kB
VmallocChunk: 34359281468 kB
HardwareCorrupted: 0 kB
AnonHugePages: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 144920 kB
DirectMap2M: 7942144 kB
Thanks,
Marc
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ | PGP 1024R/763BE901
next prev parent reply other threads:[~2014-07-06 14:58 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
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 [this message]
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=20140706145815.GD15009@merlins.org \
--to=marc@merlins.org \
--cc=andrewm@isoar.ca \
--cc=linux-btrfs@vger.kernel.org \
/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).