From owner-freebsd-stable Wed Aug 25 5:17:36 1999 Delivered-To: freebsd-stable@freebsd.org Received: from thelab.hub.org (nat203.199.mpoweredpc.net [142.177.203.199]) by hub.freebsd.org (Postfix) with ESMTP id CAE881504D for ; Wed, 25 Aug 1999 05:16:44 -0700 (PDT) (envelope-from scrappy@hub.org) Received: from localhost (scrappy@localhost) by thelab.hub.org (8.9.3/8.9.1) with ESMTP id JAA27905; Wed, 25 Aug 1999 09:16:36 -0300 (ADT) (envelope-from scrappy@hub.org) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Wed, 25 Aug 1999 09:16:36 -0300 (ADT) From: The Hermit Hacker To: Andrew Gierth Cc: freebsd-stable@FreeBSD.ORG Subject: Re: INNd sticks in "vmopar" state In-Reply-To: <87d7wc7w9r.fsf@erlenstar.demon.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 24 Aug 1999, Andrew Gierth wrote: > >>>>> "Morgan" == Morgan Davis writes: > > Morgan> Perhaps this is a question best suited for David Greenman, > Morgan> but I'll ask the -stable collective for feedback. We have a > Morgan> 3.2-STABLE news machine, connected to a Network Appliance > Morgan> (netApp) RAID. INNd 2.3 (June 11th beta) periodically gets > Morgan> stuck in a "vmopar" state. Only fix is a reboot. Looks like > Morgan> a VM system issue possibly related to NFS. Any hints or > Morgan> confirmation? > > My small news server repeatedly hangs with innd in "vmpfw", with > sometimes another process (e.g. innfeed) hung in "vmopar". Requires a > fairly aggressive reboot to fix (any attempt to unmount the news spool > filesystem hangs too). > > This is with FreeBSD-stable as of about June, with local disks and INN > 2.2-stable (with every mmap option I could find turned off). Moving to > FreeBSD-current isn't really an option. This may not be related, but... When Matt and I investigated my problem with 3.2-STABLE & INN-CURRENT (2.3 wannabe), we narrowed down the problem to a VM fragmentation problem in pre-4.x kernels. Basically, I ran 'vmstat -m' out of cron every 10 minutes, watching for the 'VM pgdata' values closely: VM pgdata 55 16K 211K128695K 73 0 0 128,256,512,2K,256K Basically, once the '211K' value reached the '128695K' value, you were hosed. By default, the system caps the 128695K(maxuse) value at something like 40M, but Matt got me to add: options "VM_KMEM_SIZE_MAX=(256*1024*1024)" to my kernel, which, at the time, jumped me to ~64M for maxuse (I had 384Meg in the machine)...the problem still happened, just not *as* quickly... Next thing we did was to increase the RAM on the machine to 768M, which doubled the maxuse size above to 128M, and the problem has disappeared... According to what I understood from Matt, it has something to do with how the VM structures are referenced, and this was radically changed in 4.x kernels... Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message