Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 09 May 2002 10:19:13 -0600
From:      Ian <freebsd@damnhippie.dyndns.org>
To:        freebsd-stable <freebsd-stable@freebsd.org>
Subject:   Re: Steadily increasing memory usage on a lightly loaded server
Message-ID:  <B8FFFDA1.CD1C%freebsd@damnhippie.dyndns.org>
In-Reply-To: <20020509143427.GA28486@student.uu.se>

next in thread | previous in thread | raw e-mail | index | archive | help


> From: Erik Trulsson <ertr1013@student.uu.se>
>> 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B8FFFDA1.CD1C%freebsd>