[no subject]

15643@apollo.backplane.com>
From: Francois Tigeot <ftigeot@wolfpond.org>
Subject: Re: Machine unresponsive with cache_lock: blocked on... message
Date: Sun, 21 Mar 2010 20:07:08 +0100
BestServHost: crater.dragonflybsd.org
List-Post: <mailto:bugs@crater.dragonflybsd.org>
List-Subscribe: <mailto:bugs-request@crater.dragonflybsd.org?body=subscribe>
List-Unsubscribe: <mailto:bugs-request@crater.dragonflybsd.org?body=unsubscribe>
List-Help: <mailto:bugs-request@crater.dragonflybsd.org?body=help>
List-Owner: <mailto:owner-bugs@crater.dragonflybsd.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <201003211824.o2LIOZUs015643@apollo.backplane.com>
Sender: bugs-errors@crater.dragonflybsd.org
Errors-To: bugs-errors@crater.dragonflybsd.org
Lines: 17
NNTP-Posting-Host: 216.240.41.25
X-Trace: 1269198514 crater_reader.dragonflybsd.org 55376 216.240.41.25
Xref: crater_reader.dragonflybsd.org dragonfly.bugs:11551

On Sun, Mar 21, 2010 at 11:24:35AM -0700, Matthew Dillon wrote:
>     Definitely try raising sysctl vfs.vm_cycle_point as Sam suggested.  This
>     can be done on a live system.  I would like to try to avoid ripping
>     up the buffer cache this close to release.

I can understand that.

>     Try setting it to 40 (it defaults to 23).  The max value is 64
>     which will effectively put all non-memory-mapped file data on the
>     inactive queue, including any data which is repeatedly accessed.

Done. I raised it previously to 30 (I think) and still had a crash.

FWIW, this machine is also running a postgres server.

-- 
Francois Tigeot