Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 24 Jun 2002 13:36:57 -0700 (PDT)
From:      Patrick Thomas <root@utility.clubscholarship.com>
To:        Matthew Dillon <dillon@apollo.backplane.com>
Cc:        Nielsen <nielsen@memberwebs.com>, <hackers@FreeBSD.ORG>, Terry Lambert <tlambert2@mindspring.com>
Subject:   Re: (jail) problem and a (possible) solution ?
Message-ID:  <20020624124558.T68572-100000@utility.clubscholarship.com>
In-Reply-To: <200206241914.g5OJEttA096925@apollo.backplane.com>

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

A few items that deserve mention, and two questions:

a) this problem occurred back when the machine had 2gigs in it - I
actually (naively) added the third gig of physical ram to try to fix the
problem.

b) another machine of mine is now exhibiting the same bahavior - it has
far fewer processes running (~500 vs ~1000) and it has only 2gigs of RAM.

questions:

1) How do I give you an entire `ps` output from DDB ?  Is there a way to
output it to a floppy or something ?  Or are you suggesting to copy down
by hand ~1000 lines of ps output ?

2) Any other suggestions as to what it is - if it doesn't look like KVA,
and I reduced my swap from 2gig to 256megs, and I reduced maxusers from
512 to 256 ... basically I have a perfectly healthy machine that crashes
for no reason ?

All of your help is greatly appreciated.  It's just so frustrating to have
it halt every day for no apparent reason - as you saw from the `top`
output just as it halted the other day , the load is trivial.

--PT


On Mon, 24 Jun 2002, Matthew Dillon wrote:

>     Well, it should be noted that there are two things going on with swap.
>     What I adjusted was the size of the swap_zone, which holds swblocks.
>     These structures hold the VM->SWAP block mappings for things that are
>     swapped out.  The swap zone eats a lot more KVA then the radix tree
>     holding the swap bitmaps.
>
>     The actual swap bitmaps are allocated from the M_SWAP malloc pool.  These
>     allocations are based on NSWAP * (largest_single_swap_area).  NSWAP
>     is usually 4.
>
>     Having a single 2GB swap area is therefore somewhat expensive, but still
>     nowhere near the size required to exhaust KVM (or even come close to
>     exhausting KVM).  It is just as expensive as having 4 x 2GB swap areas
>     due to the way the bitmaps are allocated.  The swap bitmaps eat around
>     2 bits per 4K block of swap so a single 2GB of swap will eat
>     2G/4K x 2 / 8 x NSWAP(4) = 0.5 MB of ram.  Not very much.
>
>     But, getting back to the swblocks... these use a zone, SWAPMETA
>     (vmstat -z | less, search for SWAPMETA).  The zone reserves KVA.
>     A machine with 2GB of real memory will typically reserve around 10 MB
>     of KVA to hold swblocks.  Previously it reserved 20-40 MB of KVA which
>     really ate into available KVA.  It should not be a problem now but
>     it's very easy for you to check.  Multiply the size (160) against the
>     LIMIT and you will get the approximate KVA reservation being used
>     for the SWAPMETA zone.
>
>     --
>
>     Ok, history lesson over.  Going over your original posting and the ps
>     you just posted from ddb> there is not enough information to make
>     any sort of diagnosis.  It doesn't look like KVA exhaustion to me,
>     and the ps does not show any deadlocks.  I'm not sure what is going
>     on.  I think some more experimentation is necessary... e.g. breaking into
>     DDB after it deadlocks and doing a full 'ps' (don't leave anything out
>     this time), and potentially getting a kernel core dump (assuming you
>     compiled the kernel -g and have a kernel.debug lying around that we
>     can gdb the core against).
>
> 					-Matt
> 					Matthew Dillon
> 					<dillon@backplane.com>
>
>


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020624124558.T68572-100000>