All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Weimer <fw@deneb.enyo.de>
To: xfs@oss.sgi.com
Subject: Excessive xfs_inode allocations trigger OOM killer
Date: Tue, 20 Sep 2016 21:48:42 +0200	[thread overview]
Message-ID: <87a8f2pd2d.fsf@mid.deneb.enyo.de> (raw)

I have an amd64 4.7.1 system (upstream kernel, pretty regular config)
with a small file system:

Filesystem     1K-blocks      Used Available Use% Mounted on
/dev/sda1      922595184 800396464 122198720  87% /
Filesystem        Inodes    IUsed     IFree IUse% Mounted on
/dev/sda1      504110496 15305094 488805402    4% /

The odd thing is that after a while, XFS consumes a lot of memory
according to slabtop:

  OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME                   
4121208 4121177  99%    0.88K 1030302        4   4121208K xfs_inode
986286 985229  99%    0.19K  46966       21    187864K dentry
723255 723076  99%    0.10K  18545       39     74180K buffer_head
270263 269251  99%    0.56K  38609        7    154436K radix_tree_node
140310  67409  48%    0.38K  14031       10     56124K mnt_cache

(I have attached the /proc/meminfo contents in case it offers further
clues.)

Confronted with large memory allocations (from “make -j12” and
compiling GCC, so perhaps ~8 GiB of memory), the OOM killer kicks in
and kills some random process.  I would have expected that some
xfs_inodes are freed instead.

I don't think this is an ordinary memory leak.  The last time I saw
something like the slabtop output above, I could do “sysctl
vm.drop_caches = 3”, and the amount of memory allocated reported by
slabtop was reduced considerably.  (I have not checked if the memory
was actually returned to the system.)  I have not done this now so
that I can gather further data for debugging.  I am not sure what
triggers this huge allocation.  It could be related to my Gnus mail
spool (which contains lots and lots of small files).

MemTotal:       12300808 kB
MemFree:         1744132 kB
MemAvailable:   10325076 kB
Buffers:               0 kB
Cached:          4726892 kB
SwapCached:           32 kB
Active:          3094868 kB
Inactive:        2307968 kB
Active(anon):     303736 kB
Inactive(anon):   738188 kB
Active(file):    2791132 kB
Inactive(file):  1569780 kB
Unevictable:          32 kB
Mlocked:              32 kB
SwapTotal:      14645244 kB
SwapFree:       14644796 kB
Dirty:                28 kB
Writeback:             0 kB
AnonPages:        676016 kB
Mapped:           290956 kB
Shmem:            365980 kB
Slab:            4646696 kB
SReclaimable:    4542188 kB
SUnreclaim:       104508 kB
KernelStack:        8112 kB
PageTables:        18148 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    20795648 kB
Committed_AS:    4926352 kB
VmallocTotal:   34359738367 kB
VmallocUsed:           0 kB
VmallocChunk:          0 kB
HardwareCorrupted:     0 kB
AnonHugePages:         0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:      609792 kB
DirectMap2M:    11964416 kB
DirectMap1G:     2097152 kB

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

             reply	other threads:[~2016-09-20 19:48 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-20 19:48 Florian Weimer [this message]
2016-09-20 20:30 ` Excessive xfs_inode allocations trigger OOM killer Dave Chinner
2016-09-20 20:56   ` Florian Weimer
2016-09-20 21:46     ` Dave Chinner
2016-09-21  5:45       ` Florian Weimer
2016-09-21  5:45         ` Florian Weimer
2016-09-21  5:45       ` Florian Weimer
2016-09-21  8:04       ` Michal Hocko
2016-09-21  8:06         ` Michal Hocko
2016-09-21  8:06           ` Michal Hocko
2016-09-26 17:33         ` Florian Weimer
2016-09-26 17:33           ` Florian Weimer
2016-09-26 20:02           ` Michal Hocko
2016-09-26 20:02             ` Michal Hocko
2016-10-03 17:35             ` Florian Weimer
2016-10-03 17:35               ` Florian Weimer
2016-10-03 17:54               ` Michal Hocko
2016-10-03 17:54                 ` Michal Hocko
2016-09-20 21:51 ` Christoph Hellwig
2016-09-20 21:54   ` Florian Weimer

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=87a8f2pd2d.fsf@mid.deneb.enyo.de \
    --to=fw@deneb.enyo.de \
    --cc=xfs@oss.sgi.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.