Mon Mar 22 01:40:37 PDT 2010
16061 at apollo.backplane.com>
From: Francois Tigeot <ftigeot at wolfpond.org>
Subject: Re: Machine unresponsive with cache_lock: blocked on... message
Date: Mon, 22 Mar 2010 09:39:07 +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: <201003211914.o2LJEBNo016061 at apollo.backplane.com>
Sender: bugs-errors at crater.dragonflybsd.org
Errors-To: bugs-errors at crater.dragonflybsd.org
X-Trace: 1269247340 crater_reader.dragonflybsd.org 55375 184.108.40.206
Xref: crater_reader.dragonflybsd.org dragonfly.bugs:11558
On Sun, Mar 21, 2010 at 12:14:11PM -0700, Matthew Dillon wrote:
> :> 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.
> I'd like to know if this solves your particular problem (the paging
> issue, not the crashing issue), and if so I will change the default
> cycle point for the release. So play with it.
With vfs.vm_cycle_point = 40 my server was much more responsive this morning.
Almost no programs had to be paged in when first accessed.
So far, so good.
I have now decreased vm_cycle_point to 32.
More information about the Bugs