From: Michal Hocko <mhocko@kernel.org>
To: Bruce Merry <bmerry@ska.ac.za>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Johannes Weiner <hannes@cmpxchg.org>,
Vladimir Davydov <vdavydov.dev@gmail.com>
Subject: Re: Showing /sys/fs/cgroup/memory/memory.stat very slow on some machines
Date: Wed, 18 Jul 2018 12:42:30 +0200 [thread overview]
Message-ID: <20180718104230.GC1431@dhcp22.suse.cz> (raw)
In-Reply-To: <20180717212307.d6803a3b0bbfeb32479c1e26@linux-foundation.org>
[CC some more people]
On Tue 17-07-18 21:23:07, Andrew Morton wrote:
> (cc linux-mm)
>
> On Tue, 3 Jul 2018 08:43:23 +0200 Bruce Merry <bmerry@ska.ac.za> wrote:
>
> > Hi
> >
> > I've run into an odd performance issue in the kernel, and not being a
> > kernel dev or knowing terribly much about cgroups, am looking for
> > advice on diagnosing the problem further (I discovered this while
> > trying to pin down high CPU load in cadvisor).
> >
> > On some machines in our production system, cat
> > /sys/fs/cgroup/memory/memory.stat is extremely slow (500ms on one
> > machine), while on other nominally identical machines it is fast
> > (2ms).
Could you try to use ftrace to see where the time is spent?
memory_stat_show should only scale with the depth of the cgroup
hierarchy for memory.stat to get cumulative numbers. All the rest should
be simply reads of gathered counters. There is no locking involved in
the current kernel. What is the kernel version you are using, btw?
Keeping the reset of the email for new people on the CC
> >
> > One other thing I've noticed is that the affected machines generally
> > have much larger values for SUnreclaim in /proc/memstat (up to several
> > GB), and slabtop reports >1GB of dentry.
> >
> > Before I tracked the original problem (high CPU usage in cadvisor)
> > down to this, I rebooted one of the machines and the original problem
> > went away, so it seems to be cleared by a reboot; I'm reluctant to
> > reboot more machines to confirm since I don't have a sure-fire way to
> > reproduce the problem again to debug it.
> >
> > The machines are running Ubuntu 16.04 with kernel 4.13.0-41-generic.
> > They're running Docker, which creates a bunch of cgroups, but not an
> > excessive number: there are 106 memory.stat files in
> > /sys/fs/cgroup/memory.
> >
> > Digging a bit further, cat
> > /sys/fs/cgroup/memory/system.slice/memory.stat also takes ~500ms, but
> > "find /sys/fs/cgroup/memory/system.slice -mindepth 2 -name memory.stat
> > | xargs cat" takes only 8ms.
> >
> > Any thoughts, particularly on what I should compare between the good
> > and bad machines to narrow down the cause, or even better, how to
> > prevent it happening?
> >
> > Thanks
> > Bruce
> > --
> > Bruce Merry
> > Senior Science Processing Developer
> > SKA South Africa
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2018-07-18 10:42 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAOm-9arwY3VLUx5189JAR9J7B=Miad9nQjjet_VNdT3i+J+5FA@mail.gmail.com>
2018-07-18 4:23 ` Showing /sys/fs/cgroup/memory/memory.stat very slow on some machines Andrew Morton
2018-07-18 10:42 ` Michal Hocko [this message]
2018-07-18 14:29 ` Bruce Merry
2018-07-18 14:47 ` Michal Hocko
2018-07-18 15:27 ` Bruce Merry
2018-07-18 15:33 ` Shakeel Butt
2018-07-18 15:26 ` Shakeel Butt
2018-07-18 15:37 ` Bruce Merry
2018-07-18 15:49 ` Shakeel Butt
2018-07-18 17:40 ` Bruce Merry
2018-07-18 17:48 ` Shakeel Butt
2018-07-18 17:58 ` Bruce Merry
2018-07-18 18:13 ` Shakeel Butt
2018-07-18 18:43 ` Bruce Merry
2018-07-24 10:05 ` Bruce Merry
2018-07-24 10:50 ` Marinko Catovic
2018-07-25 12:29 ` Michal Hocko
2018-07-25 12:32 ` Michal Hocko
2018-07-26 12:35 ` Bruce Merry
2018-07-26 12:48 ` Michal Hocko
2018-07-26 0:55 ` Singh, Balbir
2018-07-26 6:41 ` Bruce Merry
2018-07-26 8:19 ` 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=20180718104230.GC1431@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=bmerry@ska.ac.za \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=vdavydov.dev@gmail.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).