Sun Mar 21 12:07:45 PDT 2010
15643 at apollo.backplane.com>
From: Francois Tigeot <ftigeot at wolfpond.org>
Subject: Re: Machine unresponsive with cache_lock: blocked on... message
Date: Sun, 21 Mar 2010 20:07:08 +0100
List-Post: <mailto:bugs at crater.dragonflybsd.org>
List-Subscribe: <mailto:bugs-request at crater.dragonflybsd.org?body=subscribe>
List-Unsubscribe: <mailto:bugs-request at crater.dragonflybsd.org?body=unsubscribe>
List-Help: <mailto:bugs-request at crater.dragonflybsd.org?body=help>
List-Owner: <mailto:owner-bugs at crater.dragonflybsd.org>
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <201003211824.o2LIOZUs015643 at apollo.backplane.com>
Sender: bugs-errors at crater.dragonflybsd.org
Errors-To: bugs-errors at crater.dragonflybsd.org
X-Trace: 1269198514 crater_reader.dragonflybsd.org 55376 126.96.36.199
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.
More information about the Bugs