Date: Tue, 20 Nov 2012 14:42:45 +0200 From: Daniel Kalchev <daniel@digsys.bg> To: freebsd-fs@freebsd.org Subject: Re: SSD recommendations for ZFS cache/log Message-ID: <50AB7AC5.3020700@digsys.bg> In-Reply-To: <20121120040258.GA27849@neutralgood.org> References: <CAFHbX1K-NPuAy5tW0N8=sJD=CU0Q1Pm3ZDkVkE%2BdjpCsD1U8_Q@mail.gmail.com> <57ac1f$gf3rkl@ipmail05.adl6.internode.on.net> <50A31D48.3000700@shatow.net> <CAF6rxgkh6C0LKXOZa264yZcA3AvQdw7zVAzWKpytfh0%2BKnLOJg@mail.gmail.com> <20121116044055.GA47859@neutralgood.org> <CACpH0MfQWokFZkh58qm%2B2_tLeSby9BWEuGjkH15Nu3%2BS1%2Bp3SQ@mail.gmail.com> <50A64694.5030001@egr.msu.edu> <20121117181803.GA26421@neutralgood.org> <20121117225851.GJ1462@egr.msu.edu> <20121120040258.GA27849@neutralgood.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 20.11.12 06:02, kpneal@pobox.com wrote: > Advising people to use dedup when high dedup ratios are expected, and > advising people to otherwise not use dedup, is by itself incorrect > advice. Rather, dedup should only be enabled on a system with a large > amount of memory. The usual advice of 1G of ram per 1TB of disk is > flat out wrong. Perhaps, increasing vfs.zfs.arc_meta_limit is appropriate. It's the starvation for metadata that trashes both memory and disks. By default, that tunable is set to 1/4 of the ARC size. Perhaps 2/3 or even up to the ARC size is better. Changed in /boot/loader.conf. Just an idea, I haven't yet tested this, but from time to time do observe memory starvation from dedupe. (test pending the resilver of an 30TB array, which is abysmally slow) Daniel
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50AB7AC5.3020700>