From owner-freebsd-hackers Mon Jun 24 13:41:43 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from utility.clubscholarship.com (utility.clubscholarship.com [198.78.70.175]) by hub.freebsd.org (Postfix) with ESMTP id 55F2B37B400 for ; Mon, 24 Jun 2002 13:41:37 -0700 (PDT) Received: from localhost (root@localhost) by utility.clubscholarship.com (8.11.6/8.11.6) with ESMTP id g5OKavt42692; Mon, 24 Jun 2002 13:37:02 -0700 (PDT) (envelope-from root@utility.clubscholarship.com) Date: Mon, 24 Jun 2002 13:36:57 -0700 (PDT) From: Patrick Thomas To: Matthew Dillon Cc: Nielsen , , Terry Lambert Subject: Re: (jail) problem and a (possible) solution ? In-Reply-To: <200206241914.g5OJEttA096925@apollo.backplane.com> Message-ID: <20020624124558.T68572-100000@utility.clubscholarship.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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 > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message