From owner-freebsd-fs@FreeBSD.ORG Thu Jan 17 09:33:06 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8A8327A0; Thu, 17 Jan 2013 09:33:06 +0000 (UTC) (envelope-from nicolas@i.0x5.de) Received: from n.0x5.de (n.0x5.de [217.197.85.144]) by mx1.freebsd.org (Postfix) with ESMTP id 45FD8F36; Thu, 17 Jan 2013 09:33:05 +0000 (UTC) Received: by pc5.i.0x5.de (Postfix, from userid 1003) id 3Yn0Sq2hTVz7ySF; Thu, 17 Jan 2013 10:32:59 +0100 (CET) Date: Thu, 17 Jan 2013 10:32:59 +0100 From: Nicolas Rachinsky To: Andriy Gapon Subject: Re: slowdown of zfs (tx->tx) Message-ID: <20130117093259.GA83951@mid.pc5.i.0x5.de> References: <20130114195148.GA20540@mid.pc5.i.0x5.de> <20130114214652.GA76779@mid.pc5.i.0x5.de> <20130115224556.GA41774@mid.pc5.i.0x5.de> <50F67551.5020704@FreeBSD.org> <20130116095009.GA36867@mid.pc5.i.0x5.de> <50F69788.2040506@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50F69788.2040506@FreeBSD.org> X-Powered-by: FreeBSD X-Homepage: http://www.rachinsky.de X-PGP-Keyid: 887BAE72 X-PGP-Fingerprint: 039E 9433 115F BC5F F88D 4524 5092 45C4 887B AE72 X-PGP-Keys: http://www.rachinsky.de/nicolas/gpg/nicolas_rachinsky.asc User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 09:33:06 -0000 * Andriy Gapon [2013-01-16 14:05 +0200]: > on 16/01/2013 12:14 Steven Hartland said the following: > > You only have ~11% free so yer it is pretty full ;-) > > just in case, Steve is not kidding. > > Those free hundreds of gigabytes could be spread over the terabytes and could be > quite fragmented if the pool has a history of adding and removing lots of files. > ZFS could be spending quite a lot of time in that case when it looks for some > free space and tries to minimize further fragmentation. > > Empirical/anecdotal safe limit on pool utilization is said to be about 70-80%. > > You can test if this guess is true by doing the following: > kgdb -w > (kgdb) set metaslab_min_alloc_size=4096 > > If performance noticeably improves after that, then this is your problem indeed. I tried this, but I didn't notice any difference in performance. Next I'll try the update Artem suggested. Thanks Nicolas -- http://www.rachinsky.de/nicolas