From owner-freebsd-stable Thu May 9 9:19:17 2002 Delivered-To: freebsd-stable@freebsd.org Received: from damnhippie.dyndns.org (12-253-177-2.client.attbi.com [12.253.177.2]) by hub.freebsd.org (Postfix) with ESMTP id 352A137B414 for ; Thu, 9 May 2002 09:19:12 -0700 (PDT) Received: from [172.22.42.2] (peace.hippie.lan [172.22.42.2]) by damnhippie.dyndns.org (8.11.6/8.11.6) with ESMTP id g49GJBG86067 for ; Thu, 9 May 2002 10:19:11 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) User-Agent: Microsoft Outlook Express Macintosh Edition - 5.01 (1630) Date: Thu, 09 May 2002 10:19:13 -0600 Subject: Re: Steadily increasing memory usage on a lightly loaded server From: Ian To: freebsd-stable Message-ID: In-Reply-To: <20020509143427.GA28486@student.uu.se> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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 > 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. 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. I have a feeling there's some missing piece of info involved. Like, the discussion of the VM design needs to be considered in view of some other fact (not obvious to me) to properly explain most of a system's ram being in the "inactive" category after a while. For example, I can boot my development machine and let it sit idle for weeks and most of the ram (like 180 of 256 MB) stays in the Free category. Then I run a make buildworld and upon completion there's 180 MB inactive and under 10MB left in Free. But after the buildworld is completed it doesn't leave any processes laying around that can own 180 MB of inactive pages, so how did that ram end up in the inactive category in light of the VM discussion at the URL above? What process owns those pages but hasn't referenced them recently? 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). -- Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message