Jason,
Yes, it does make sense and something that we at Delphix have discussed.
This tunable was the first attempt at making this adjustable so expect
to see more in this space as things continue to evolve.
Thanks,
George
On 11/24/14, 11:52 AM, Jason Cox wrote:
(I apologize if this has been posted on the list from me already. I
have had some issues and not sure if it was successfully posted yet or
not)
My company has been dealing with fragmentation issues on ZFS with some
heavy write OLTP databases and performance problems overtime as the DB
grows and data is written. We have come to the point that every so
often (once a quarter or so), we defragment it by creating new LUNs
and doing a ZFS send/receive. Over time we have learned to create
more, smaller LUNs so that we get more vdevs thus more/smaller
metaslabs on the pool and better write performance to the SAN without
having to mess with zfs_vdev_max_pending as much. (Please note that we
are currently using Oracle Solaris 11, but I have been making the case
to switch to an Illumos based OS instead to take advantage of some of
the improvements that have come out)
I was doing some digging recently and found that back in September, a
change was committed:
"5161 add tunable for number of metaslabs per vdev
https://reviews.csiden.org/r/95/";
My question is does it make sense to just have a tunable to say how
many metaslabs per vdev only or could we look at the option of having
a knob that lets you set the maximum size you would prefer per
metaslab and then have the code determine the number of metaslabs per
vdev automagicly? Would it make sense to try to optimize the metaslabs
size like that? Is there a point that a high number of metaslabs
affects performance in some way?
Anyways I look forward to being able to use the new option of setting
the number of metaslabs per vdev in time. Improvements like this help
me move my case forward for a change.
--Jason
_______________________________________________
developer mailing list
[email protected]
http://lists.open-zfs.org/mailman/listinfo/developer
_______________________________________________
developer mailing list
[email protected]
http://lists.open-zfs.org/mailman/listinfo/developer
