On Aug 8, 2009, at 5:02 AM, Ed Spencer wrote:
On Fri, 2009-08-07 at 19:33, Richard Elling wrote:
This is very unlikely to be a "fragmentation problem." It is a
scalability problem
and there may be something you can do about it in the short term.
You could be right.
Out test mail server consists of the exact same design, same hardware
(SUN4V) but in a smaller configuration (less memory and 4 x 25g san
luns) has a backup/copy thoughput of 30GB/hour. Data used for testing
was "copied" from our production mail server.
Adding another pool and copying all/some data over to it would only
a short term solution.
I'll have to disagree.
What is the point of a filesystem the can grow to such a huge size and
not have functionality built in to optimize data layout? Real world
implementations of filesystems that are intended to live for
years/decades need this functionality, don't they?
Our mail system works well, only the backup doesn't perform well.
All the features of ZFS that make reads perform well (prefetch, ARC)
have little effect.
The best workload is one that doesn't read from disk to begin with :-)
For workloads with millions of files (eg large-scale mail servers) you
will need to increase the size of the Directory Name Lookup Cache
(DNLC). By default, it is way too small for such workloads. If the
directory names are in cache, then they do not have to be read from
disk -- a big win.
You can see how well the DNLC is working by looking at the output of
"vmstat -s" and look for the "total name lookups." You can size DNLC
by tuning the ncsize parameter, but it requires a reboot. See the
Solaris Tunable Parameters Guide for details.
http://docs.sun.com/app/docs/doc/817-0404/chapter2-35?a=view
I'd like to revisit the backup problem, but that is much more
complicated
and probably won't fit in a mail thread very easily (hence, the white
paper :-)
-- richard
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
