Date: Tue, 29 Jan 2013 15:48:52 +0100 From: Gergely CZUCZY <gergely.czuczy@harmless.hu> To: Nicolas Rachinsky <fbsd-mas-0@ml.turing-complete.org> Cc: freebsd-fs <freebsd-fs@FreeBSD.org>, Andriy Gapon <avg@FreeBSD.org> Subject: Re: slowdown of zfs (tx->tx) Message-ID: <20130129154852.000021f1@unknown> In-Reply-To: <20130117093259.GA83951@mid.pc5.i.0x5.de> References: <20130114195148.GA20540@mid.pc5.i.0x5.de> <CAFqOu6jwJ4qhbOovN_NhzusdQJvrbvUC3g93sziR=Uw99SGenw@mail.gmail.com> <20130114214652.GA76779@mid.pc5.i.0x5.de> <CAFqOu6jKX-Ks6C1RK5GwZ51ZVUSnGSe7S99_EfK%2BfwLPjAFFYw@mail.gmail.com> <20130115224556.GA41774@mid.pc5.i.0x5.de> <CAFqOu6jJnWdbikPmE1-UML5i_x7meF%2BiyY=9WBRyv2j7AeOaSg@mail.gmail.com> <50F67551.5020704@FreeBSD.org> <20130116095009.GA36867@mid.pc5.i.0x5.de> <FD780217EA4548F187715AF1AAF2B91A@multiplay.co.uk> <50F69788.2040506@FreeBSD.org> <20130117093259.GA83951@mid.pc5.i.0x5.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello, Once think we've noticed on our systems, might be unrelated, but still. After heavy usage of dedup, our ZFS pools tended to slow down drastically. The solution was to deallocate and reallocate dedup-enabled filesystems (copying or send/recieving data back and forth). Just an idea, might be unrelated in your case. Best regards, Gergely On Thu, 17 Jan 2013 10:32:59 +0100 Nicolas Rachinsky <fbsd-mas-0@ml.turing-complete.org> wrote: > * Andriy Gapon <avg@FreeBSD.org> [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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130129154852.000021f1>