Greeting ALL I am wondering if it is possible to monitor the ZFS ARC cache hits using DTRACE. In orher words, would be possible to know how many ARC cache hits have been resulted by a particular application such as firefox ?? Your response is highly appreciated. Thanks -- Abdullah DAHLAWI at IEEE.ORG (IM) ieee2007 at hotmail.com ---- Check The Fastest 500 Super Computers Worldwide http://www.top500.org/list/2009/11/100 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100209/6fe8d94f/attachment.html>
Abdullah, On Tue, Feb 09, 2010 at 02:12:24PM -0500, Abdullah Al-Dahlawi wrote:> Greeting ALL > > I am wondering if it is possible to monitor the ZFS ARC cache hits using > DTRACE. In orher words, would be possible to know how many ARC cache hits > have been resulted by a particular application such as firefox ??ZFS has kstat for a whole bunch of these. You could run "kstat -m zfs" and see if which ones help you. Correlating these stats to a particular application would be a little difficult. Using Dtrace, you could track down the read/write operations and see if they lead to a hit/miss in ARC. Take a look at the routine arc_read here : http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/arc.c "ARCSTAT_BUMP(arcstat_hits);" is the routine which increments the hit count. You could track arc_read()s called from the context of the application and check if it causes a hit or a miss. Thanks and regards, Sanjeev> > Your response is highly appreciated. > > > Thanks > > > -- > Abdullah > DAHLAWI at IEEE.ORG > (IM) ieee2007 at hotmail.com > ---- > Check The Fastest 500 Super Computers Worldwide > http://www.top500.org/list/2009/11/100-- ---------------- Sanjeev Bagewadi Solaris RPE Bangalore, India
Hi Sanjeev
linking the application to the ARCSTAT_BUMP(arcstat_hits) is not
straightforward and time consuming especially if I am running many
experiments.
Brendan has commented on on the post by providing an alternative DTrace
script , here is his post ...
------------------
dtrace -n ''sdt:::arc-hit { @[execname] = count(); }''
Or to filter just on firefox:
dtrace -n ''sdt:::arc-hit /execname == "firefox-bin"/ { @ =
count(); }''
If neither of them work, it just means that that particular sdt provider
probe wasn''t available, and we can get this information from using the
fbt
provider instead.
Note: ZFS prefetch is pretty effective, so streaming reads from disk will
often
show up as arc hits since ZFS has put the data in cache before the
application
reads it. Which is the intent.
------------------------
I ran Brendan script while watching arcstat from kstat and notice great deal
of discrepancy in terms of cache hits & misses numbers between kstat &
Brendan''s scrip. I am not sure exactly where ''sdt''
probe collects the cache
hits information !!.
Any feed back ?
On Wed, Feb 10, 2010 at 11:43 PM, Sanjeev <sanjeev.bagewadi at sun.com>
wrote:
> Abdullah,
>
> On Tue, Feb 09, 2010 at 02:12:24PM -0500, Abdullah Al-Dahlawi wrote:
> > Greeting ALL
> >
> > I am wondering if it is possible to monitor the ZFS ARC cache hits
using
> > DTRACE. In orher words, would be possible to know how many ARC cache
hits
> > have been resulted by a particular application such as firefox ??
>
> ZFS has kstat for a whole bunch of these. You could run "kstat -m
zfs" and
> see
> if which ones help you.
>
> Correlating these stats to a particular application would be a little
> difficult.
>
> Using Dtrace, you could track down the read/write operations and see if
> they
> lead to a hit/miss in ARC. Take a look at the routine arc_read here :
>
>
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/arc.c
>
> "ARCSTAT_BUMP(arcstat_hits);" is the routine which increments the
hit
> count.
>
> You could track arc_read()s called from the context of the application and
> check
> if it causes a hit or a miss.
>
> Thanks and regards,
> Sanjeev
> >
> > Your response is highly appreciated.
> >
> >
> > Thanks
> >
> >
> > --
> > Abdullah
> > DAHLAWI at IEEE.ORG
> > (IM) ieee2007 at hotmail.com
> > ----
> > Check The Fastest 500 Super Computers Worldwide
> > http://www.top500.org/list/2009/11/100
>
>
> --
> ----------------
> Sanjeev Bagewadi
> Solaris RPE
> Bangalore, India
>
--
Abdullah Al-Dahlawi
http://www.google.com/profiles/aldahlawi
----
Check The Fastest 500 Super Computers Worldwide
http://www.top500.org/list/2009/11/100
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100211/1bf76132/attachment.html>
Abdullah, On Thu, Feb 11, 2010 at 03:42:38PM -0500, Abdullah Al-Dahlawi wrote:> Hi Sanjeev > > linking the application to the ARCSTAT_BUMP(arcstat_hits) is not > straightforward and time consuming especially if I am running many > experiments. > > Brendan has commented on on the post by providing an alternative DTrace > script , here is his post ... > ------------------ > dtrace -n ''sdt:::arc-hit { @[execname] = count(); }'' > > Or to filter just on firefox: > > dtrace -n ''sdt:::arc-hit /execname == "firefox-bin"/ { @ = count(); }'' > > If neither of them work, it just means that that particular sdt provider > probe wasn''t available, and we can get this information from using the fbt > provider instead. > > Note: ZFS prefetch is pretty effective, so streaming reads from disk will > often > show up as arc hits since ZFS has put the data in cache before the > application > reads it. Which is the intent. > ------------------------ > I ran Brendan script while watching arcstat from kstat and notice great deal > of discrepancy in terms of cache hits & misses numbers between kstat & > Brendan''s scrip. I am not sure exactly where ''sdt'' probe collects the cache > hits information !!.The DTrace probe which collects the info is right above the location that I mentioned. Look for lines similar to : "DTRACE_PROBE1(arc__hit, arc_buf_hdr_t *, hdr);" in zfs/arc.c. The script which Brendan has mentioned tracks only those which are caused by the application that you are tracking. Whereas, kstat values are for the entire arc. Hence, they would be completely different (kstat numbers would be much higher). Are you noticing this pattern or is it something else ? Thanks and regards, Sanjeev> On Wed, Feb 10, 2010 at 11:43 PM, Sanjeev <sanjeev.bagewadi at sun.com> wrote: > > > Abdullah, > > > > On Tue, Feb 09, 2010 at 02:12:24PM -0500, Abdullah Al-Dahlawi wrote: > > > Greeting ALL > > > > > > I am wondering if it is possible to monitor the ZFS ARC cache hits using > > > DTRACE. In orher words, would be possible to know how many ARC cache hits > > > have been resulted by a particular application such as firefox ?? > > > > ZFS has kstat for a whole bunch of these. You could run "kstat -m zfs" and > > see > > if which ones help you. > > > > Correlating these stats to a particular application would be a little > > difficult. > > > > Using Dtrace, you could track down the read/write operations and see if > > they > > lead to a hit/miss in ARC. Take a look at the routine arc_read here : > > > > http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/arc.c > > > > "ARCSTAT_BUMP(arcstat_hits);" is the routine which increments the hit > > count. > > > > You could track arc_read()s called from the context of the application and > > check > > if it causes a hit or a miss. > > > > Thanks and regards, > > Sanjeev > > > > > > Your response is highly appreciated. > > > > > > > > > Thanks > > > > > > > > > -- > > > Abdullah > > > DAHLAWI at IEEE.ORG > > > (IM) ieee2007 at hotmail.com > > > ---- > > > Check The Fastest 500 Super Computers Worldwide > > > http://www.top500.org/list/2009/11/100 > > > > > > -- > > ---------------- > > Sanjeev Bagewadi > > Solaris RPE > > Bangalore, India > > > > > > -- > Abdullah Al-Dahlawi > http://www.google.com/profiles/aldahlawi > ---- > Check The Fastest 500 Super Computers Worldwide > http://www.top500.org/list/2009/11/100-- ---------------- Sanjeev Bagewadi Solaris RPE Bangalore, India