All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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.