Date: Tue, 15 Oct 2013 09:25:32 +0100 From: krad <kraduk@gmail.com> To: Zaphod Beeblebrox <zbeeble@gmail.com> Cc: Tom Evans <tevans.uk@googlemail.com>, john@potato.growveg.org, FreeBSD FS <freebsd-fs@freebsd.org> Subject: Re: RAM and zfs and multiple disks Message-ID: <CALfReyfff3EeewWGLQtOx-EU_628PFGfa3T14VJP4hnWiZ7V_g@mail.gmail.com> In-Reply-To: <CACpH0MeMzFwHbzvLYh-wd%2BQ3%2BCmO-qpVhqgPANjkcCqX0Rwh-A@mail.gmail.com> References: <20131010170724.GA19751@potato.growveg.org> <CAFHbX1%2BVhK08wzLJfgH2exPgCbFvrWeo5dCksfyHQ691br%2BMEA@mail.gmail.com> <CACpH0MeMzFwHbzvLYh-wd%2BQ3%2BCmO-qpVhqgPANjkcCqX0Rwh-A@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
on thing worth noting about dedup is that its not an all or nothing option
as you can tune it per file system. Also you only need the humongous amount
of ram when you do writes, which of course is quite a common thing to do.
However there are scenarios where a dataset will dedup quite well, but isnt
written to often (os repo archive etc). You can potentially enable dedup on
these and take the write performance hit. You can sometimes get away with
is on databases as well, where the dataset is large and highly dedupable,
but doesnt change much. What I have done in the past is enable dedup on the
initial data load, and then disable it before deploying to production. In
this case you get the benefits of the space saving, but not the hits when
you write, as newly written data isnt deduped. This is a special case
though so wont suit most as over time depending on write patterns the
dataset could grow much bigger.
As previously mentioned one of the cheapest ways to make it viable is to
add a big chunk of SSD for L2ARC. Before you think doing this though check
whether its even worth considering on your data by doing a zdb -S <pool>.
It will give you the expected dedup ratio
eg os pool from my main server
root@#:/home/krad# zdb -S rpool
Simulated DDT histogram:
bucket allocated referenced
______ ______________________________ ______________________________
refcnt blocks LSIZE PSIZE DSIZE blocks LSIZE PSIZE DSIZE
------ ------ ----- ----- ----- ------ ----- ----- -----
1 460K 31.4G 26.1G 26.1G 460K 31.4G 26.1G 26.1G
2 33.8K 822M 580M 580M 69.8K 1.67G 1.17G 1.17G
4 2.34K 50.1M 31.3M 31.3M 10.8K 254M 156M 156M
8 417 12.8M 5.26M 5.26M 4.29K 134M 55.5M 55.5M
16 131 1.52M 555K 555K 2.70K 29.4M 9.54M 9.54M
32 45 62.5K 51K 51K 1.73K 2.48M 2.02M 2.02M
64 7 3.50K 3.50K 3.50K 602 301K 301K 301K
128 5 130K 130K 130K 991 17.3M 17.3M 17.3M
Total 497K 32.3G 26.7G 26.7G 551K 33.5G 27.5G 27.5G
dedup = 1.03, compress = 1.22, copies = 1.00, dedup * compress / copies =
1.25
and a vm pool
root@radical:/home/krad# zdb -S vm1
Simulated DDT histogram:
bucket allocated referenced
______ ______________________________ ______________________________
refcnt blocks LSIZE PSIZE DSIZE blocks LSIZE PSIZE DSIZE
------ ------ ----- ----- ----- ------ ----- ----- -----
1 1.28M 164G 102G 102G 1.28M 164G 102G 102G
2 17.8K 2.23G 1.21G 1.21G 40.9K 5.11G 2.75G 2.75G
4 1.25K 160M 85.7M 85.7M 5.70K 730M 374M 374M
8 176 22M 6.33M 6.33M 1.72K 220M 63.6M 63.6M
16 24 3M 1019K 1019K 540 67.5M 22.8M 22.8M
32 4 512K 71.5K 71.5K 163 20.4M 2.49M 2.49M
64 5 640K 22.5K 22.5K 383 47.9M 1.68M 1.68M
128 2 256K 12K 12K 342 42.8M 1.92M 1.92M
256 2 256K 9K 9K 715 89.4M 3.14M 3.14M
512 1 128K 4.50K 4.50K 570 71.2M 2.50M 2.50M
Total 1.30M 167G 103G 103G 1.33M 171G 105G 105G
dedup = 1.02, compress = 1.62, copies = 1.00, dedup * compress / copies =
1.65
Having said all that as everyone else has said I wouldnt thought it would
be much use on a desktop, and 8 GB of ram it will run fine. Limiting arc as
people have suggested, shouldnt really be necessary as its mainly there to
stop memory fragmentation, and a few special application cases, generally
though it just works and you can leave it alone.
On 11 October 2013 16:58, Zaphod Beeblebrox <zbeeble@gmail.com> wrote:
> At home I have a large ZFS server serving up 18x 2T disks (raidZ1 x2). The
> server machine is core2-duo with 8G RAM and an 'em' GigE added (because the
> motherboard GigE was crap). I use SATA port expanders to multiply the 6
> motherboard ports. The machine has a UFS boot and there is a bit of a
> "fight" when something uses memory and/or UFS to do something.
>
> I would have had ZFS on my desktop, but instead I use a diskless NFS setup
> from the ZFS server. Originally, when I setup these systems, the NFS
> diskless desktop was avoiding the conflict between the nvidia driver being
> 32 bit only and ZFS liking more memory. This is long moot, but the setup
> remains. The only remaining task here is to use NFSv4 diskless. I'm not
> sure how easy/hard that is. The root mount seems to be NFSv3.
>
> As for ZFS on desktops, all the PC-BSD setups I've done for the family are
> ZFS. They typically have either 2 or 4 gig of RAM. I haven't really tried
> a low memory ZFS (say 512 meg). They seem to run acceptably well, but they
> aren't really challenging anything --- running a FreeBSD/gnome or
> FreeBSD/KDE desktop on a machine with 2 or 4 gig of RAM is really not a
> challenge.
> _______________________________________________
> freebsd-fs@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CALfReyfff3EeewWGLQtOx-EU_628PFGfa3T14VJP4hnWiZ7V_g>