Date: Wed, 25 Aug 1999 09:16:36 -0300 (ADT) From: The Hermit Hacker <scrappy@hub.org> To: Andrew Gierth <andrew@erlenstar.demon.co.uk> Cc: freebsd-stable@FreeBSD.ORG Subject: Re: INNd sticks in "vmopar" state Message-ID: <Pine.BSF.4.10.9908250909340.86612-100000@thelab.hub.org> In-Reply-To: <87d7wc7w9r.fsf@erlenstar.demon.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On 24 Aug 1999, Andrew Gierth wrote:
> >>>>> "Morgan" == Morgan Davis <mdavis@cts.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9908250909340.86612-100000>