From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by kanga.kvack.org (Postfix) with ESMTP id 82D8B6B4CAF for ; Wed, 29 Aug 2018 12:44:42 -0400 (EDT) Received: by mail-wr1-f71.google.com with SMTP id l45-v6so3842051wre.4 for ; Wed, 29 Aug 2018 09:44:42 -0700 (PDT) Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id x189-v6sor1393516wmg.10.2018.08.29.09.44.40 for (Google Transport Security); Wed, 29 Aug 2018 09:44:40 -0700 (PDT) MIME-Version: 1.0 References: <6ef03395-6baa-a6e5-0d5a-63d4721e6ec0@suse.cz> <20180823122111.GG29735@dhcp22.suse.cz> <76c6e92b-df49-d4b5-27f7-5f2013713727@suse.cz> <8b211f35-0722-cd94-1360-a2dd9fba351e@suse.cz> <20180829150136.GA10223@dhcp22.suse.cz> <20180829152716.GB10223@dhcp22.suse.cz> In-Reply-To: <20180829152716.GB10223@dhcp22.suse.cz> From: Marinko Catovic Date: Wed, 29 Aug 2018 18:44:27 +0200 Message-ID: Subject: Re: Caching/buffers become useless after some time Content-Type: multipart/alternative; boundary="000000000000bd2c92057495acfb" Sender: owner-linux-mm@kvack.org List-ID: To: Michal Hocko Cc: Vlastimil Babka , Christopher Lameter , linux-mm@kvack.org --000000000000bd2c92057495acfb Content-Type: text/plain; charset="UTF-8" > > one host is at a healthy state right now, I'd run that over there > immediately. > > Let's see what we can get from here. > oh well, that went fast. actually with having low values for buffers (around 100MB) with caches around 20G or so, the performance was nevertheless super-low, I really had to drop the caches right now. This is the first time I see it with caches >10G happening, but hopefully this also provides a clue for you. Just after starting the stats I reset from previously defer to madvise - I suspect that this somehow caused the rapid reaction, since a few minutes later I saw that the free RAM jumped from 5GB to 10GB, after that I went afk, returning to the pc since my monitoring systems went crazy telling me about downtime. If you think changing /sys/kernel/mm/transparent_hugepage/defrag back to its default, while it was on defer now for days, was a mistake, then please tell me. here you go: https://nofile.io/f/VqRg644AT01/vmstat.tar.gz trace_pipe: https://nofile.io/f/wFShvZScpvn/trace_pipe.gz --000000000000bd2c92057495acfb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

> one host is at a healthy state right now, I'd run that over there = immediately.

Let's see what we can get from here.

oh well, that went fast. actually with having low values for buffers= (around 100MB) with caches
around 20G or so, the performance was= nevertheless super-low, I really had to drop
the caches right no= w. This is the first time I see it with caches >10G happening, but hopef= ully
this also provides a clue for you.

<= div>Just after starting the stats I reset from previously defer to madvise = - I suspect that this somehow
caused the rapid reaction, since a = few minutes later I saw that the free RAM jumped from 5GB to 10GB,
after that I went afk, returning to the pc since my monitoring systems we= nt crazy telling me about downtime.

If you thi= nk changing /sys/kernel/mm/transparent_hugepage/defrag back to its default, while it was
on defer now for days, was a mistake, then please tell me.

--000000000000bd2c92057495acfb--