ZFS question - clones vs dedupe in terms of performance

Z

zag

Hello to everyone,

what you will recommend in terms of performance - zfs clonings or zfs dedupe.

I have 3Tb of disk space (HP EVA) with one Oracle database - size 1,2T . I need 8 copies of this DB for test and development purposes on the same storage. I'm thinking for 2 possibilities:

1. 8 clones
2. 8 copies with zfs send/recv on the same storage with dedupe switched on

The server is with 22G RAM, 2x Xeon CPU 5160 3.00GHz".

What you will recommend?


Regards: Ivan
 
I would go with cloning.

There are many reports of dedupe causing bad performance and generally taking vast amounts of memory. Also in your instance, cloning seems to make more sense seeing as you just need 8 copies of the original data. Dedupe is useful when you don't have as much control over what's being stored or it changes often and there may be large amounts of duplicate data - network share storing user files for example or VM storage (although I personally would rather give up the disk space and save performance/memory for VMs).

Cloning also will be instant, and as it's basically just using the snapshot logic, shouldn't perform any differently to a standard ZFS filesystem that has snapshots. You can drop a clone or create new ones whenever you want within seconds.

With dedupe you will need to make sure dedupe is on BEFORE the original data is put onto the pool, and then create 8 copies, which will take almost as long as copying the data without dedupe.
 
If they are initially the same and then evolve in different directions then there are 2 equivalent options:
*clone
*dedupe on->copy data->dedupe off->work
I think that turning dedupe off should resolve performance problems, but changes are not deduped, just like with a clone. If there is a desire to dedupe changes too, you should just keep it on. After all I recommend the dedupe way, because if there are no performance issues, you're better off. If there are - you can just disable it.
 
From my experience, the writing of files with dedup=on is very slow. However, reading the files afterwards are extremely quick (since the same blocks might be cached already).

But I cannot think why it should be much better than cloning the same dataset, since you will also be reading the same blocks (cached) for all cloned files until you change a block which would then be newly written to disk.

So, without a benchmark my bet would be that the read performance will be about equal, and probably more dependent on cache size than whether you use clone or dedup.

regards
Malan

P.S. If you want to rollback the database to an original state after testing each time I guess snapshot + clone will be the optimal answer.
 
From my personal experience with dedup I would say stay well clear of it. There are several posts on the opensolaris mailing lists of people having issues with zfs destroy when dedup is enabled. The short version is it consumes all the system's memory causing the system to crash. It takes multiple restarts and several days for zfs to recover. And I'm not talking about systems with 1-4G of RAM, they're all systems with 16G+ RAM.

This article gives a good explanation of the cost (i.e. amount of RAM required) to use zfs with dedup.
 
You must log in or register to reply here.
Back
Top