[dtrace-discuss] [Fwd: [zfs-discuss] DTrace IO provider and oracle]

Roch Roch.Bourbonnais at Sun.COM
Wed Aug 9 06:58:27 PDT 2006


przemolicc at poczta.fm writes:

 > Hello,
 > 
 > I have sent the following e-mail by mistake to zfs-discuss. Anyway Tao Chen answered my question.
 > But I would like to ask a more general question: since oracle uses its database files by
 > mmap (am I right ?) 

I think not. I/O is Mostly driven through O_DSYNC writes.

 > how can I (d)trace io activity to mmap-ed files ? 

In terms of I/O to storage the fact that files are mmaped
does not change the ability to dtrace into the I/O. With ZFS 
it takes some experience to decode what the I/O actually
correspond to.

But if your interested in seeing the modification to
in-memory mmaped locations then that is whole different ball 
game. You should be able to observe an initial pagefault on first
touch but after that you won't be hitting any traceable point.

 > According to
 > http://docs.sun.com/app/docs/doc/817-0404/6mg74vs9i?a=view
 > fsflush is the proces which flushes dirty pages to disk. Is fsflush the only one system process
 > which "touches" mmap-ed files ?

Note that any process that fsync or msync the said file will
initiate some I/O as well.

 > 
 > przemol
 > 
 > ----- Forwarded message from przemolicc at poczta.fm -----
 > 
 > > From: przemolicc at poczta.fm
 > > To: zfs-discuss at opensolaris.org
 > > Subject: [zfs-discuss] DTrace IO provider and oracle
 > > Date: Tue, 8 Aug 2006 15:54:26 +0200
 > > 
 > > Hello,
 > > 
 > > Solaris 10 GA + latest recommended patches:
 > > 
 > > while runing dtrace:
 > > 
 > > bash-3.00# dtrace -n 'io:::start {@[execname, args[2]->fi_pathname] = count();}'
 > > ...
 > >   vim                                                 /zones/obsdb3/root/opt/sfw/bin/vim                              296
 > >   tnslsnr                                             <none>                                                         2373
 > >   fsflush                                             <none>                                                         2952
 > >   sched                                               <none>                                                         9949
 > >   ar60run                                             <none>                                                        13590
 > >   RACUST                                              <none>                                                        39252
 > >   RAXTRX                                              <none>                                                        39789
 > >   RAXMTR                                              <none>                                                        40671
 > >   FNDLIBR                                             <none>                                                        64956
 > >   oracle                                              <none>                                                      2096052
 > > 
 > > How can I interpret '<none>' ? Is it possible to get full path (like in vim) ?
 > 
 > Section "27.2.3 fileinfo_t" of DTrace Guide
 > explains in detail why you see '<none>' in many cases.
 > http://www.sun.com/bigadmin/content/dtrace/d10_latest.pdf
 > or
 > http://docs.sun.com/app/docs/doc/817-6223/6mlkidllf?a=view
 > 
 > The "execname" part can also be misleading, as many I/O activities are
 > "asynchronous" (including but not limited to Asynchronous I/O), so whatever
 > thread running on CPU may have nothing to do with the I/O that's occuring.
 > 
 > This is working as designed and not a "problem" that limited to ZFS, IMO.
 > 
 > Tao
 > 
 > 
 > > 
 > > Regards
 > > przemol
 > > _______________________________________________
 > > zfs-discuss mailing list
 > > zfs-discuss at opensolaris.org
 > > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
 > 
 > ----- End forwarded message -----
 > _______________________________________________
 > dtrace-discuss mailing list
 > dtrace-discuss at opensolaris.org



More information about the dtrace-discuss mailing list