On Dec 23, 2009, at 3:00 PM, Michael Herf wrote:
For me, arcstat.pl is a slam-dunk predictor of dedup throughput. If
my "miss%" is in the single digits, dedup write speeds are
reasonable. When the arc misses go way up, dedup writes get very
slow. So my guess is that this issue depends entirely on whether or
not the DDT is in RAM or not. I don't have any L2ARC.
Yep, seems consistent with my tests. I'm currently seeing 43.6
million zap-unique
entries consume approximately 12 GBytes of metadata space. This is
dog slow to
write on a machine with only 8 GBytes of RAM and a single HDD in the
pool. The
writes are relatively fast, but all of the time is spent doing random
reads, which is
not a recipe for success with HDDs.
I don't know the ARC design exactly, but I can imagine that DDT is
getting flushed out by other filesystem activity, even though
keeping it in RAM is very critical to write performance.
e.g., currently I'm doing a big chmod -R, an rsync, and a zfs send/
receive (when jobs like this take a week, it piles up.) And right
now my miss% is consistently >50% on a machine with 6GB ram. My
writes are terrifically slow, like 3MB/sec.
Can anyone comment if it is possible to tell the kernel/ARC "keep
more DDT in RAM"?
If not, could it be possible in a future kernel?
I'm leaning to the notion that an SSD cache device will be required
for any sort
of dedup performance. Or a huge amount of RAM, of course :-)
Unfortunately,
the DDT routines are not currently instrumented (b129), so it might
take a while
to fully understand what instrumentation would be most useful.
-- richard
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
