Date: Thu, 9 May 2002 17:04:26 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Erik Trulsson <ertr1013@student.uu.se> Cc: freebsd-stable <freebsd-stable@FreeBSD.ORG> Subject: Re: Steadily increasing memory usage on a lightly loaded server Message-ID: <200205100004.g4A04Q2n029553@apollo.backplane.com> References: <20020509143427.GA28486@student.uu.se> <B8FFFDA1.CD1C%freebsd@damnhippie.dyndns.org> <20020509164709.GA29822@student.uu.se>
next in thread | previous in thread | raw e-mail | index | archive | help
:
: 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.
:
:<Insert your favourite quote here.>
:Erik Trulsson
:ertr1013@student.uu.se
You are correct. If the system is not being stressed you can wind
up with a large number of pages marked 'active' which are really
inactive, and a large number of pages marked 'inactive' which are
really cache. The original posting had this:
Mem: 23M Active, 618M Inact, 69M Wired, 40M Cache, 86M Buf, 1328K Free
This looks like a fairly unstressed system to me. The actual definitions
for the page queues are:
wired - similar to 'active' but these pages are wired into the
kernel (typically mapped to the kernel's buffer cache).
active - pages which the system will NOT try to free any time soon.
These pages may be clean or dirty and may be mapped to
user processes.
inactive - pages which are candidates for cleaning/freeing, which
have not been accessed in a long time (relative to the
'active' queue).
These pages may be clean or dirty and may still be mapped
to processes (but the processes haven't accessed the pages
recently).
These pages have a 'bent' towards being more accessible
and it generally does not cost a demand-page exception
to reactivate them. It costs a cleaning/unmapping cycle
in order to be able to free these pages.
cache - pages which the system can free and reuse with no notice.
These pages are still effectively 'disk cache' in that
an attempt to access them will cause a reactivation (move
them back to the active queue), but these pages are
guarenteed to be clean and not mapped to any process so
the system can simply steal them if it needs a free page
and doesn't have enough in the 'free' queue.
These pages have a 'bent' towards being more free and it
costs the system a demand-page exception to reactivate them.
It does not cost anything for the system to free/reuse
these pages.
free - truely free pages
In a lightly loaded system pages tend to stay 'active' or 'inactive'.
After all, there is no reason to unmap a page from a process's address
space even if the page is not being actively accessed until you absolutely
have to! It takes memory pressure in order to force the system to work
the queues.
Memory pressure takes the form of allocating a new page. The system
will first look for a completely free page from the 'free' queue. If
it can't find one it will look for a page in the 'cache' queue. If the
system notices that memory pressure has created a shortfall of free or
cache pages the system will 'clean' pages from the inactive queue and
move them to the cache queue (if the page is already 'clean' this only
involves unmapping the page from user processes address spaces). This
movement can create a shortfall in the inactive queue which causes the
system to move pages from the active queue to the inactive queue.
In a very heavily loaded system memory pressure occurs from two
directions. Memory allocations put memory pressure on the page
queues from the 'free' queue upwards, and programs accessing memory
put pressure on the 'active' queue downwards. You can visualize it
as two entities pulling on the queues from both ends at the same time.
Under extreme loads these two pressures stretch the queues beyond
their limits and the system is forced to start deactivating pages which
are still active, and is also forced to stall processes trying to
allocate new pages. This is fine until we get to the point where
the deactivated page is cleaned/freed before the original process
can reactivate it again, which means the system starts doing extra
disk I/Os. This is the definition of page 'thrashing'. At this
point the system starts taking emergency measures like enforced
process swapouts. But, as you can see, in FreeBSDland it takes
truely extreme memory pressure to create such a situation.
-Matt
Matthew Dillon
<dillon@backplane.com>
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?200205100004.g4A04Q2n029553>