Date: Mon, 07 Nov 2011 19:35:34 +0000 From: Johannes Totz <jtotz@imperial.ac.uk> To: freebsd-fs@freebsd.org Subject: Re: ZFS question - clones vs dedupe Message-ID: <j99bu6$8s8$1@dough.gmane.org> In-Reply-To: <CA%2Bwowm92R%2BM4-Z-sr20ngnNnm8PN5DTpNi40UX-O%2BAKRoJjfQA@mail.gmail.com> References: <CA%2Bwowm92R%2BM4-Z-sr20ngnNnm8PN5DTpNi40UX-O%2BAKRoJjfQA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 31/10/2011 10:34, Ivan Natchkov wrote: > Hello to everyone, > > I have the following situation. EVA 4000 with 3T disk space and one > oracle DB 1,2T on a different storage. On our EVA we must keep copy of > this DB with non stop applying of archive logs. In addition we need > 3-4 development DB's plus 3-4 test DB's which are copies of the > original 1,2T DB and are stored on the EVA. We are thinking about 2 > scenarios. 1) 8 clonings with keeping differences between the clonings > 2) to have 8 different DB made with zfs send/receive on the same > storage with deduplication switch ON. > > In both scenario we want the DB with applying logs to be with dedupe > switched off because of the performance issues. > > I have 20 Gigs of RAM and the DDT table is possible to be kept in it > with some tuning of sysctl. > > Which scenario would you recommend in terms of performance? I don't understand your requirement, so cannot give a recommendation. However, I've been playing with dedup for the past few weeks and so far I have mixed feelings about it. There are some stability issues (zfs bits keeps live-locking sometimes) and write-performance kinda sucks. Especially deleting larger sets of data (like snapshots or big files) takes ages, up to a point that makes SSH logins take a few minutes. Also, after a crash it takes very long to boot up again, maybe because it's rolling back some transactions or something... I have about 1.5 TB of data, dedup ratio is around 1.7. The machine only has 6 GB of RAM, and I've increased the metadata limit to 4 GB. However, I log actual arc-size periodically and very often it's nowhere near its limit... Oh yeah, and there's lzjb compression as well. This prob adds a bit of trouble, see compression thread from a few weeks ago. Johannes
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?j99bu6$8s8$1>