Richard Elling wrote:
...
Most folks who want performance data collection all day long will
enable accounting and use sar. sar also uses kstats. Or you can
write your own scripts. Or there are a number of third party tools
which will collect long-term stats and provide nice reports or
On Sun, Jan 18, 2009 at 9:21 AM, Carson Gaspar car...@taltos.org wrote:
If you write your own using kstat, you can get accurate sub-second
samples. Sadly you'll either have to use the amazingly crappy Sun perl
or write it in C, as Sun hasn't yet managed to release source for the
kstat perl
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:
Well if I do fsstat mountpoint on all the filesystems in the ZFS pool, then I
guess my aggregate number for read and write bandwidth should equal the
aggregate numbers for the pool? Yes?
The downside is that fsstat has the same granularity issue as zpool iostat.
What I'd really like is nread
On Sun, Jan 18, 2009 at 5:39 PM, Brad bst...@aspirinsoftware.com wrote:
Well if I do fsstat mountpoint on all the filesystems in the ZFS pool, then I
guess my aggregate number for read and write bandwidth should equal the
aggregate numbers for the pool? Yes?
The downside is that fsstat has
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:
On Sun, Jan 18, 2009 at 8:25 PM, Richard Elling richard.ell...@sun.com wrote:
Peter Tribble wrote:
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
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
Carson Gaspar wrote:
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
I'd like to track a server's ZFS pool I/O throughput over time. What's a good
data source to use for this? I like zpool iostat for this, but if I poll at two
points in time I would get a number since boot (e.g. 1.2M) and a current number
(e.g. 1.3K). If I use the current number then I've lost
Brad,
I'd like to track a server's ZFS pool I/O throughput over time.
What's a good data source to use for this? I like zpool iostat for
this, but if I poll at two points in time I would get a number since
boot (e.g. 1.2M) and a current number (e.g. 1.3K). If I use the
current number
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
-
From: Thomas Garner thomas...@gmail.com
To: Brad bst...@aspirinsoftware.com
Cc: zfs-discuss@opensolaris.org
Sent: Saturday, January 17, 2009 4:04 PM
Subject: Re: [zfs-discuss] Aggregate Pool I/O
Are you looking for something like:
kstat -c disk sd:::
Someone can correct me if I'm wrong
Brad wrote:
I'd like to track a server's ZFS pool I/O throughput over time. What's a good
data source to use for this? I like zpool iostat for this, but if I poll at
two points in time I would get a number since boot (e.g. 1.2M) and a current
number (e.g. 1.3K). If I use the current number
14 matches
Mail list logo