[CentOS] Re: why is this machine using swap space?

Fri Jul 21 17:52:44 UTC 2006
William L. Maltby <BillsCentOS at triad.rr.com>

On Fri, 2006-07-21 at 12:36 -0500, Larry Vaden wrote:
> On 7/21/06, William L. Maltby <BillsCentOS at triad.rr.com> wrote:
> > On Fri, 2006-07-21 at 12:10 -0500, Larry Vaden wrote:
> > > On 7/21/06, Scott Silva <ssilva at sgvwater.com> wrote:
> > > > Larry Vaden spake the following on 7/21/2006 8:05 AM:
> > > > ><snip><snip>

> Here's what got my curiosity up (and wondering why the swap'd item(s)
> didn't eventually expire);  the first machine is running sendmail, the
> others are running postfix.
> 
> Mem:   1025076k total,   602508k used,   422568k free,    42204k buffers
> Swap:  2031608k total,      600k used,  2031008k free,   506496k cached
> 
> Mem:   1295916k total,   719596k used,   576320k free,    70192k buffers
> Swap:  2031608k total,      144k used,  2031464k free,   441984k cached
> 
> <snip similar>

In that thread was mentioned a "feature" that came to be considered a
bug. That's why U4 is supposed to remove it. That *maight* affect what
we are seeing. You can reduce even that by using the "swappiness" thing
and considering the other actions mentioned in that thread.

What you show is *not* a problem, IMO, but an irritation. I believe the
memory manager just dumps some *really* inactive pages out so that
buffers and cache (which should be *very* active areas) can get more
memory.

<straight face>
Makes since: why maintain an error trapping routine in memory at the
expense of buffers and/or cache? We *know* there are no bugs that need
trapping, right?
</straight face>

> rgds/ldv
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> http://lists.centos.org/mailman/listinfo/centos
-- 
Bill
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.centos.org/pipermail/centos/attachments/20060721/8c8694c1/attachment-0005.sig>