From owner-freebsd-stable Thu May 9 9:47:26 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mailf.telia.com (mailf.telia.com [194.22.194.25]) by hub.freebsd.org (Postfix) with ESMTP id DF3FA37B40E for ; Thu, 9 May 2002 09:47:16 -0700 (PDT) Received: from d1o913.telia.com (d1o913.telia.com [195.252.44.241]) by mailf.telia.com (8.11.6/8.11.6) with ESMTP id g49GlB915709 for ; Thu, 9 May 2002 18:47:11 +0200 (CEST) Received: from falcon.midgard.homeip.net (h53n2fls20o913.telia.com [212.181.163.53]) by d1o913.telia.com (8.8.8/8.8.8) with SMTP id SAA16777 for ; Thu, 9 May 2002 18:47:10 +0200 (CEST) Received: (qmail 29857 invoked by uid 1001); 9 May 2002 16:47:09 -0000 Date: Thu, 9 May 2002 18:47:09 +0200 From: Erik Trulsson To: freebsd-stable Subject: Re: Steadily increasing memory usage on a lightly loaded server Message-ID: <20020509164709.GA29822@student.uu.se> Mail-Followup-To: freebsd-stable References: <20020509143427.GA28486@student.uu.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.99i Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, May 09, 2002 at 10:19:13AM -0600, Ian wrote: > > > > From: Erik Trulsson > >> See http://www.freebsd.org/doc/en_US.ISO8859-1/articles/vm-design/x78.html > >> for details. > > > > It seems you are right, and my understanding of which was which of the > > 'Inactive', 'Cached' and 'Buf' categories was not quite correct. > > > > My main point still stands though in that having lots of memory moved > > from 'Free' to 'Inactive' is normal and nothing to worry about. > > > > If the discussion at the URL above is up to date and applicable to -STABLE > then I'm not sure we've properly explained where that memory is going, even > if "don't worry" is the right answer to the original question. I believe the discussion in the vm-design article was written with 4.x in mind so it should be both up to date and applicable. > > The discussion of the VM design indicates that "inactive" memory is memory > marked as dirty (needing pageout before reassigning the page), but that > memory hasn't been referenced recently and would make a good candidate for a > pageout if the need arises. If this is correct, then the original question > stands: why does a system with a known very light workload gradually move > from having 700 MB free to having almost all of that 700 MB marked as dirty > and just not used recently. That sounds a lot like a memory leak in one of > the processes. Except, a casual glance at the before/after pictures with > top doesn't show any process getting bigger. [snip] > Hrm. On a reread of the design discussion, I notice "nor does it move pages > between the various page queues gratuitously when the memory subsystem is > not being stressed." Does this imply that much of of the memory on the > inactive queue would be on the cache queue, but there was no need to waste > cycles moving them to another queue because there was no demand for them? > It strikes me as counter-intuitive that a queue of pages that are "dirty but > not recently referenced" would also hold pages that are no longer owned by a > process (and thus not really dirty). Later on in the article one can find the following paragraphs: Yes, that is confusing. The relationship is `goal'' verses `reality''. Our goal is to separate the pages but the reality is that if we are not in a memory crunch, we do not really have to. What this means is that FreeBSD will not try very hard to separate out dirty pages (inactive queue) from clean pages (cache queue) when the system is not being stressed, nor will it try to deactivate pages (active queue -> inactive queue) when the system is not being stressed, even if they are not being used. My interpretation is that the inactive queue does not really hold pages that are "dirty but not recently referenced" but rather pages that are "possibly dirty and not recently referenced", while the cache queue holds pages that are known not to be dirty. This probably means that under a normal load most of the pages in the inactive queue are not in fact dirty. -- Erik Trulsson ertr1013@student.uu.se To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message