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 > <[EMAIL PROTECTED]> > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
