Richard Elling wrote: ... > 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.
The problem is that even for long term trending you need better than 10 minute resolution, unless your app isn't bursty at all, or you leave a _lot_ of headroom (or you only care about throughput and not latency). Sadly, most (but by no means all) 3rd party tools are resource hogs themselves, so aren't very good for permanent resource utilization tracking (although they can be amazing at application performance debugging). One of the really cool things about dtrace is its extremely low perormance impact. Thus, my (trimmed in the quote) recommendation to write your own using kstat, as opposed to relying on sar. Or go buy something, but in my experience sar is unlikely to make you happy. -- Carson _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
