Peter Tribble wrote: > On Sat, Jan 17, 2009 at 9:04 PM, Thomas Garner <thomas...@gmail.com> wrote: >> Are you looking for something like: >> >> kstat -c disk sd::: >> >> Someone can correct me if I'm wrong, but I think the documentation for >> the above should be at: >> >> http://src.opensolaris.org/source/xref/zfs-crypto/gate/usr/src/uts/common/avs/ns/sdbc/cache_kstats_readme.txt >> >> I'm not sure about the file i/o vs disk i/o, but would love to hear >> how to measure it. > > See fsstat, which is based upon kstats. One of the thing I want to do with > JKstat is correlate filesystem operations with underlying disk operations. The > hard part is actually connecting a filesystem to the underlying drives. That's > harder with zfs as the disk I/O is mapped to a pool which has multiple > filesystems.
If we draw a stack with application on top, devices on bottom then fsstat shows the load into the file system from above. iostat shows load into the devices from above. But because file systems like to do things like caching, wrangling metadata, prefetching, coalescing, deferring writes, and prewriting data (eg ZIL). it is really hard to make a 1:1 correlation between an application's I/O activity and disk I/O -- except for a rather small subset of overall activity. This is one reason some databases like to deal with raw devices. It is also why performance work for databases is often done with raw devices -- fewer moving parts. The upshot is that if you are looking for a 1:1 relationship, you will be sad. Rather, it is better to look at overall efficiencies, which are fairly well presented. > (The same is true with soft partitions under SVM, but with zfs sharing is the > rule rather than the exception.) > > I would like to see the pool statistics exposed as kstats, though, which would > make it easier to analyse them with existing tools. I recall some discussion about kstats in ZFS for performance a few years ago, but IIRC the concensus seemed to be that ZFS was not going to get overloaded with zillions of kstats. BTW, I really like Peter's work on JKstat -- well done! Carson Gaspar wrote: > Except sar sucks. It's scheduled via cron, and is too coarse grained for > many purposes (10 minute long samples average out almost everything > interesting). There is a world of difference between the tools needed to perform debugging and performance improvements vs long-term trending. sar is a big, warty beast, but it works reasonably well for long-term trending. The 3rd party tools like TeamQuest are more modern and do a better job -- you get what you pay for. -- richard _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
