Date: Mon, 28 Oct 2013 11:25:25 -0700 From: aurfalien <aurfalien@gmail.com> To: Slawa Olhovchenkov <slw@zxy.spb.ru> Cc: freebsd-fs <freebsd-fs@freebsd.org>, freebsd-current@freebsd.org Subject: Re: ZFS txg implementation flaw Message-ID: <B1D05034-056B-4E0C-A52B-ECB8CA1F4F04@gmail.com> In-Reply-To: <20131028181631.GV63359@zxy.spb.ru> References: <20131028092844.GA24997@zxy.spb.ru> <0F1D571E-2806-4392-A5EC-BE66A3C92BF7@gmail.com> <20131028181631.GV63359@zxy.spb.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Oct 28, 2013, at 11:16 AM, Slawa Olhovchenkov wrote: > On Mon, Oct 28, 2013 at 10:45:02AM -0700, aurfalien wrote: >=20 >>=20 >> On Oct 28, 2013, at 2:28 AM, Slawa Olhovchenkov wrote: >>=20 >>> I can be wrong. >>> As I see ZFS cretate seperate thread for earch txg writing. >>> Also for writing to L2ARC. >>> As result -- up to several thousands threads created and destoyed = per >>> second. And hundreds thousands page allocations, zeroing, maping >>> unmaping and freeing per seconds. Very high overhead. >>>=20 >>> In systat -vmstat I see totfr up to 600000, prcfr up to 200000. >>>=20 >>> Estimated overhead -- 30% of system time. >>>=20 >>> Can anybody implement thread and page pool for txg? >>=20 >> Would lowering vfs.zfs.txg.timeout be a way to tame or mitigate this? >=20 > vfs.zfs.txg.timeout: 5 >=20 > Only x5 lowering (less in real case with burst writing). And more = fragmentation on writing and etc. So leave it default in other words. Good to know. - aurf
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B1D05034-056B-4E0C-A52B-ECB8CA1F4F04>