Date: Sat, 24 Jun 2006 12:08:29 -0500 From: "Matthew D. Fuller" <fullermd@over-yonder.net> To: Chuck Swiger <cswiger@mac.com> Cc: freebsd-stable@freebsd.org Subject: Re: vmstat 'b' (disk busy?) field keeps climbing ... Message-ID: <20060624170829.GO83482@over-yonder.net> In-Reply-To: <449CB3C4.2060509@mac.com> References: <20060623172557.H1114@ganymede.hub.org> <261AD16B-C3FE-4671-996E-563053508CE8@mac.com> <20060623191131.C1114@ganymede.hub.org> <20060623231121.GL83482@over-yonder.net> <20060623220204.L1114@ganymede.hub.org> <20060624013305.GN83482@over-yonder.net> <20060623225437.C1114@ganymede.hub.org> <449CB3C4.2060509@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jun 23, 2006 at 11:38:44PM -0400 I heard the voice of
Chuck Swiger, and lo! it spake thus:
>
> Yeah-- it's more common for a system to need more RAM for dynamicly
> allocated content which would be placed into the swapfile then it
> uses binary executable pages, it's possible to go the other way,
> too.
Yeah, and it's WAY the other way.
0 swap pager pageins
0 swap pager pageouts
31750 vnode pager pageins
15954 vnode pager pageouts
That speaks of HUGE memory pressure in program text; plenty for the
'data' of the programs, but really really tight for the programs
themselves. That'll also lead to a lot of disk thrashing. And there
aren't even all that many fork() calls, relative to my box (of course,
mine does things like ports builds that spawn of totally stupid
numbers of processes, so that may be a quirk here rather than there).
Perhaps rebuilding a bunch of stuff with -Os will gain you some
breathing room, but more memory or less load is probably the only real
answer. And I think you already had 4 gig in an i386 box, so you're
kinda in trouble on the memory side.
--
Matthew Fuller (MF4839) | fullermd@over-yonder.net
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060624170829.GO83482>