From: Chris Down <chris@chrisdown.name>
To: Stefan Priebe - Profihost AG <s.priebe@profihost.ag>
Cc: cgroups@vger.kernel.org,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
Michal Hocko <mhocko@kernel.org>,
Johannes Weiner <hannes@cmpxchg.org>,
"n.fahldieck@profihost.ag" <n.fahldieck@profihost.ag>,
Daniel Aberger - Profihost AG <d.aberger@profihost.ag>,
p.kramme@profihost.ag
Subject: Re: No memory reclaim while reaching MemoryHigh
Date: Thu, 25 Jul 2019 10:53:55 -0400 [thread overview]
Message-ID: <20190725145355.GA7347@chrisdown.name> (raw)
In-Reply-To: <496dd106-abdd-3fca-06ad-ff7abaf41475@profihost.ag>
Hi Stefan,
Stefan Priebe - Profihost AG writes:
>While using kernel 4.19.55 and cgroupv2 i set a MemoryHigh value for a
>varnish service.
>
>It happens that the varnish.service cgroup reaches it's MemoryHigh value
>and stops working due to throttling.
In that kernel version, the only throttling we have is reclaim-based throttling
(I also have a patch out to do schedule-based throttling, but it's not in
mainline yet). If the application is slowing down, it likely means that we are
struggling to reclaim pages.
>But i don't understand is that the process itself only consumes 40% of
>it's cgroup usage.
>
>So the other 60% is dirty dentries and inode cache. If i issue an
>echo 3 > /proc/sys/vm/drop_caches
>
>the varnish cgroup memory usage drops to the 50% of the pure process.
As a caching server, doesn't Varnish have a lot of hot inodes/dentries in
memory? If they are hot, it's possible it's hard for us to evict them.
>I thought that the kernel would trigger automatic memory reclaim if a
>cgroup reaches is memory high value to drop caches.
It does, that's the throttling you're seeing :-) I think more information is
needed to work out what's going on here. For example: what do your kswapd
counters look like? What does "stops working due to throttling" mean -- are you
stuck in reclaim?
Thanks,
Chris
next prev parent reply other threads:[~2019-07-25 14:53 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-25 13:17 No memory reclaim while reaching MemoryHigh Stefan Priebe - Profihost AG
2019-07-25 14:01 ` Michal Hocko
2019-07-25 21:37 ` Stefan Priebe - Profihost AG
2019-07-26 7:45 ` Michal Hocko
2019-07-26 18:30 ` Stefan Priebe - Profihost AG
2019-07-28 21:11 ` Stefan Priebe - Profihost AG
2019-07-28 21:39 ` Chris Down
2019-07-29 5:34 ` Stefan Priebe - Profihost AG
2019-07-29 7:07 ` Stefan Priebe - Profihost AG
2019-07-29 7:45 ` Stefan Priebe - Profihost AG
2019-07-31 13:03 ` Michal Hocko
2019-07-25 14:53 ` Chris Down [this message]
2019-07-25 21:42 ` Stefan Priebe - Profihost AG
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=20190725145355.GA7347@chrisdown.name \
--to=chris@chrisdown.name \
--cc=cgroups@vger.kernel.org \
--cc=d.aberger@profihost.ag \
--cc=hannes@cmpxchg.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=n.fahldieck@profihost.ag \
--cc=p.kramme@profihost.ag \
--cc=s.priebe@profihost.ag \
/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.