Re: [dtrace-discuss] Can I pass a parameter to Dtrace script as a part of function name?

2009-01-16 Thread Steve Scargall
$1 is not a D variable it's a shell var.  Have a look at the "inline" 
function/operand.  
http://wikis.sun.com/display/DTrace/Type+and+Constant+Definitions

There's loads of examples in the DTrace Toolkit that you can look at and use as 
examples.   Google "dtrace inline" for more examples.
-- 
This message posted from opensolaris.org
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org


[dtrace-discuss] Can I pass a parameter to Dtrace script as a part of function name?

2009-01-16 Thread Qihua Wu
I want to trace function whose name has certain value, such as "read" or
"write". But seems dtrace can't replace the variable with the value I passed
in.

bash-3.00$ cat d.d
#!/usr/sbin/dtrace -s

#pragma D option flowindent

syscall::**$1**:entry { self->interest = 1; }
fbt::: /self->interest/ {}
syscall::**$1**:return { self->interest = 0; }



bash-3.00$ ./d.d *read*
dtrace: failed to compile script ./d.d: line 5: invalid probe description "*
syscall::*$1*:entry*": Undefined macro variable in probe description
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org

Re: [dtrace-discuss] C++ Applications with Dtrace

2009-01-16 Thread David Lutz
If I understand it correctly, the alloc fail for sbrk_top is just
an indication that the heap had to be grown, which is different
than other failures, which would indicate that we ran out of
memory.

Have a look at:

http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libumem/common/vmem_sbrk.c

David

- Original Message -
From: "Pavesi, Valdemar (NSN - US/Boca Raton)" 
Date: Friday, January 16, 2009 3:24 pm

> Hello,
> 
> I have a example of memory leak.
> 
> What does means the  alloc fail=  335 ?
> 
> 
> # mdb -p 1408
> Loading modules: [ ld.so.1 libumem.so.1 libc.so.1 libuutil.so.1 ]
> > ::findleaks -dv
> findleaks:maximum buffers => 14920
> findleaks: actual buffers => 14497
> findleaks:
> findleaks: potential pointers => 316574898
> findleaks: dismissals => 309520985 (97.7%)
> findleaks: misses => 6929221   ( 2.1%)
> findleaks:   dups => 110601( 0.0%)
> findleaks:follows => 14091 ( 0.0%)
> findleaks:
> findleaks:  elapsed wall time => 54 seconds
> findleaks:
> BYTES LEAKED VMEM_SEG CALLER
> 4096   4 fd7ffc539000 MMAP
> 16384  1 fd7ffe83d000 MMAP
> 4096   1 fd7ffe812000 MMAP
> 8192   1 fd7ffd7bc000 MMAP
> 24016397  124a2a0 libstdc++.so.6.0.8`_Znwm+0x1e
> 
>Total 401 oversized leaks, 9567120 bytes
> 
> CACHE LEAKED   BUFCTL CALLER
> 004cf468   1 0050ed20 libstdc++.so.6.0.8`_Znwm+0x1e
> 004cf468   1 0050c000 libstdc++.so.6.0.8`_Znwm+0x1e
> 004cf468   1 0050ea80 libstdc++.so.6.0.8`_Znwm+0x1e
> 004cf468   1 0050c0e0 libstdc++.so.6.0.8`_Znwm+0x1e
> 004cf468   1 0050ee00 libstdc++.so.6.0.8`_Znwm+0x1e
> --
>Total   5 buffers, 80 bytes
> 
> mmap(2) leak: [fd7ffc539000, fd7ffc53a000), 4096 bytes
> mmap(2) leak: [fd7ffe83d000, fd7ffe841000), 16384 bytes
> mmap(2) leak: [fd7ffe812000, fd7ffe813000), 4096 bytes
> mmap(2) leak: [fd7ffd7bc000, fd7ffd7be000), 8192 bytes
> umem_oversize leak: 397 vmem_segs, 24016 bytes each, 9534352 bytes total
> ADDR TYPESTART  END SIZE
> THREADTIMESTAMP
>  124a2a0 ALLC  1252000  1257dd024016
>  1 56bd6f2a6fe1
>  libumem.so.1`vmem_hash_insert+0x90
>  libumem.so.1`vmem_seg_alloc+0x1c4
>  libumem.so.1`vmem_xalloc+0x50b
>  libumem.so.1`vmem_alloc+0x15a
>  libumem.so.1`umem_alloc+0x60
>  libumem.so.1`malloc+0x2e
>  libstdc++.so.6.0.8`_Znwm+0x1e
>  libstdc++.so.6.0.8`_Znam+9
> 
>  
> 
> >   ::umastat
> cachebufbufbufmemory alloc alloc
> namesize in use  totalin use   succeed  fail
> - -- -- -- - - -
> umem_magazine_1   16  5101  4096 6 
> 0
> umem_magazine_3   32356378 24576   356 
> 0
> umem_magazine_7   64 20 84  819292 
> 0
> umem_magazine_15 128 11 21  409611 
> 0
> umem_magazine_31 256  0  0 0 0 
> 0
> umem_magazine_47 384  0  0 0 0 
> 0
> umem_magazine_63 512  0  0 0 0 
> 0
> umem_magazine_95 768  0  0 0 0 
> 0
> umem_magazine_143   1152  0  0 0 0 
> 0
> umem_slab_cache   56638650 53248   638 
> 0
> umem_bufctl_cache 24  0  0 0 0 
> 0
> umem_bufctl_audit_cache  192  15328  15336   3489792 15328 
> 0
> umem_alloc_8   8  0  0 0 0 
> 0
> umem_alloc_16 16 79170  8192   2098631 
> 0
> umem_alloc_32 32267320 20480   306 
> 0
> umem_alloc_48 48   4653   4692376832  6028 
> 0
> umem_alloc_64 64   5554   5568712704 12642 
> 0
> umem_alloc_80 80   2492   2520286720  5185 
> 0
> umem_alloc_96 96492512 65536   654 
> 0
> umem_alloc_112   112 95112 16384   103 
> 0
> umem_alloc_128 

Re: [dtrace-discuss] C++ Applications with Dtrace

2009-01-16 Thread Pavesi, Valdemar (NSN - US/Boca Raton)
Here the memory leaks was fixed.

We still have allocation fail = 169 .


mdb -p 2103
Loading modules: [ ld.so.1 libumem.so.1 libc.so.1 libuutil.so.1 ]
> ::findleaks -dv
findleaks:maximum buffers => 14499
findleaks: actual buffers => 14080
findleaks:
findleaks: potential pointers => 316492344
findleaks: dismissals => 309494621 (97.7%)
findleaks: misses => 6875689   ( 2.1%)
findleaks:   dups => 107963( 0.0%)
findleaks:follows => 14071 ( 0.0%)
findleaks:
findleaks:  elapsed wall time => 9 seconds
findleaks:
BYTES LEAKED VMEM_SEG CALLER
4096   4 fd7ffc539000 MMAP
16384  1 fd7ffe83d000 MMAP
4096   1 fd7ffe812000 MMAP
8192   1 fd7ffd7bc000 MMAP

   Total   4 oversized leaks, 32768 bytes

CACHE LEAKED   BUFCTL CALLER
004cf468   1 0050ed20 libstdc++.so.6.0.8`_Znwm+0x1e
004cf468   1 0050c000 libstdc++.so.6.0.8`_Znwm+0x1e
004cf468   1 0050ea80 libstdc++.so.6.0.8`_Znwm+0x1e
004cf468   1 0050c0e0 libstdc++.so.6.0.8`_Znwm+0x1e
004cf468   1 0050ee00 libstdc++.so.6.0.8`_Znwm+0x1e
--
   Total   5 buffers, 80 bytes

mmap(2) leak: [fd7ffc539000, fd7ffc53a000), 4096 bytes
mmap(2) leak: [fd7ffe83d000, fd7ffe841000), 16384 bytes
mmap(2) leak: [fd7ffe812000, fd7ffe813000), 4096 bytes
mmap(2) leak: [fd7ffd7bc000, fd7ffd7be000), 8192 bytes

>  ::umastat
cachebufbufbufmemory alloc alloc
namesize in use  totalin use   succeed  fail
- -- -- -- - - -
umem_magazine_1   16  5101  4096 6 0
umem_magazine_3   32356378 24576   356 0
umem_magazine_7   64 25 84  819285 0
umem_magazine_15 128 11 21  409611 0
umem_magazine_31 256  0  0 0 0 0
umem_magazine_47 384  0  0 0 0 0
umem_magazine_63 512  0  0 0 0 0
umem_magazine_95 768  0  0 0 0 0
umem_magazine_143   1152  0  0 0 0 0
umem_slab_cache   56638650 53248   638 0
umem_bufctl_cache 24  0  0 0 0 0
umem_bufctl_audit_cache  192  15328  15336   3489792 15328 0
umem_alloc_8   8  0  0 0 0 0
umem_alloc_16 16 82170  8192876682 0
umem_alloc_32 32267320 20480   306 0
umem_alloc_48 48   4654   4692376832  5785 0
umem_alloc_64 64      5568712704 10210 0
umem_alloc_80 80   2492   2520286720  3727 0
umem_alloc_96 96492512 65536   654 0
umem_alloc_112   112 95112 16384   103 0
umem_alloc_128   128 38 42  819242 0
umem_alloc_160   160 12 21  409686 0
umem_alloc_192   192  2 16  4096 2 0
umem_alloc_224   224  5 16  4096   361 0
umem_alloc_256   256  1 12  4096 1 0
umem_alloc_320   320  7   1010413696234010 0
umem_alloc_384   384 34 36 1638441 0
umem_alloc_448   448  5  8  409610 0
umem_alloc_512   512  1  7  4096 2 0
umem_alloc_640   640 11 22 1638416 0
umem_alloc_768   768  2  9  8192   180 0
umem_alloc_896   896  1  4  4096 2 0
umem_alloc_1152 1152 11 20 24576   127 0
umem_alloc_1344 1344  4 40 61440  7175 0
umem_alloc_1600 1600  3  7 12288 5 0
umem_alloc_2048 2048  2  9 20480 6 0
umem_alloc_2688 2688  5  7 2048010 0
umem_alloc_4096 4096  6  7 57344   335 0
umem_alloc_8192 8192118119   1462272   321 0
umem_alloc_12288   12288 19 21344064   241 0
umem_alloc_16384 

Re: [dtrace-discuss] C++ Applications with Dtrace

2009-01-16 Thread Pavesi, Valdemar (NSN - US/Boca Raton)

Hello,

I have a example of memory leak.

What does means the  alloc fail=  335 ?


# mdb -p 1408
Loading modules: [ ld.so.1 libumem.so.1 libc.so.1 libuutil.so.1 ]
> ::findleaks -dv
findleaks:maximum buffers => 14920
findleaks: actual buffers => 14497
findleaks:
findleaks: potential pointers => 316574898
findleaks: dismissals => 309520985 (97.7%)
findleaks: misses => 6929221   ( 2.1%)
findleaks:   dups => 110601( 0.0%)
findleaks:follows => 14091 ( 0.0%)
findleaks:
findleaks:  elapsed wall time => 54 seconds
findleaks:
BYTES LEAKED VMEM_SEG CALLER
4096   4 fd7ffc539000 MMAP
16384  1 fd7ffe83d000 MMAP
4096   1 fd7ffe812000 MMAP
8192   1 fd7ffd7bc000 MMAP
24016397  124a2a0 libstdc++.so.6.0.8`_Znwm+0x1e

   Total 401 oversized leaks, 9567120 bytes

CACHE LEAKED   BUFCTL CALLER
004cf468   1 0050ed20 libstdc++.so.6.0.8`_Znwm+0x1e
004cf468   1 0050c000 libstdc++.so.6.0.8`_Znwm+0x1e
004cf468   1 0050ea80 libstdc++.so.6.0.8`_Znwm+0x1e
004cf468   1 0050c0e0 libstdc++.so.6.0.8`_Znwm+0x1e
004cf468   1 0050ee00 libstdc++.so.6.0.8`_Znwm+0x1e
--
   Total   5 buffers, 80 bytes

mmap(2) leak: [fd7ffc539000, fd7ffc53a000), 4096 bytes
mmap(2) leak: [fd7ffe83d000, fd7ffe841000), 16384 bytes
mmap(2) leak: [fd7ffe812000, fd7ffe813000), 4096 bytes
mmap(2) leak: [fd7ffd7bc000, fd7ffd7be000), 8192 bytes
umem_oversize leak: 397 vmem_segs, 24016 bytes each, 9534352 bytes total
ADDR TYPESTART  END SIZE
THREADTIMESTAMP
 124a2a0 ALLC  1252000  1257dd024016
 1 56bd6f2a6fe1
 libumem.so.1`vmem_hash_insert+0x90
 libumem.so.1`vmem_seg_alloc+0x1c4
 libumem.so.1`vmem_xalloc+0x50b
 libumem.so.1`vmem_alloc+0x15a
 libumem.so.1`umem_alloc+0x60
 libumem.so.1`malloc+0x2e
 libstdc++.so.6.0.8`_Znwm+0x1e
 libstdc++.so.6.0.8`_Znam+9

 

>   ::umastat
cachebufbufbufmemory alloc alloc
namesize in use  totalin use   succeed  fail
- -- -- -- - - -
umem_magazine_1   16  5101  4096 6 0
umem_magazine_3   32356378 24576   356 0
umem_magazine_7   64 20 84  819292 0
umem_magazine_15 128 11 21  409611 0
umem_magazine_31 256  0  0 0 0 0
umem_magazine_47 384  0  0 0 0 0
umem_magazine_63 512  0  0 0 0 0
umem_magazine_95 768  0  0 0 0 0
umem_magazine_143   1152  0  0 0 0 0
umem_slab_cache   56638650 53248   638 0
umem_bufctl_cache 24  0  0 0 0 0
umem_bufctl_audit_cache  192  15328  15336   3489792 15328 0
umem_alloc_8   8  0  0 0 0 0
umem_alloc_16 16 79170  8192   2098631 0
umem_alloc_32 32267320 20480   306 0
umem_alloc_48 48   4653   4692376832  6028 0
umem_alloc_64 64   5554   5568712704 12642 0
umem_alloc_80 80   2492   2520286720  5185 0
umem_alloc_96 96492512 65536   654 0
umem_alloc_112   112 95112 16384   103 0
umem_alloc_128   128 38 42  819242 0
umem_alloc_160   160 12 21  409686 0
umem_alloc_192   192  2 16  4096 2 0
umem_alloc_224   224  5 16  4096   848 0
umem_alloc_256   256  1 12  4096 1 0
umem_alloc_320   320  7   1010413696560719 0
umem_alloc_384   384 34 36 1638441 0
umem_alloc_448   448  5  8  409610 0
umem_alloc_512   512  1  7  4096 2 0
umem_alloc_640  

Re: [dtrace-discuss] C++ Applications with Dtrace

2009-01-16 Thread David Lutz
Hi Venkat,

I believe "alloc succeed" is a count of memory requests that
were successful.  That memory may have been freed later,
so it doesn't necessarily point to the reason for a growing
memory foot print.   The column to be concerned with is
"memory in use".

David

- Original Message -
From: venkat 
Date: Friday, January 16, 2009 2:44 pm

> Hi david,
> 
> 
> What is allocated succeed  block from umastat dcmd . that value is 
> keep on increasing . Is that memory occupieng by process?
>   like that way my process  memory usage also keep on increasing ?
> 
> can u clarify plz ?
> 
> 
> Thanks,
>  Venkat
> -- 
> This message posted from opensolaris.org
> ___
> dtrace-discuss mailing list
> dtrace-discuss@opensolaris.org
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org


Re: [dtrace-discuss] C++ Applications with Dtrace

2009-01-16 Thread venkat
Hi david,


What is allocated succeed  block from umastat dcmd . that value is keep on 
increasing . Is that memory occupieng by process?
  like that way my process  memory usage also keep on increasing ?

can u clarify plz ?


Thanks,
 Venkat
-- 
This message posted from opensolaris.org
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org


Re: [dtrace-discuss] Programmatic interface to DTrace?

2009-01-16 Thread Kedar Mhaswade
Excellent resource, Chris. Thank you.
-- 
This message posted from opensolaris.org
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org


Re: [dtrace-discuss] Programmatic interface to DTrace?

2009-01-16 Thread Chris Andrews
On Fri, Jan 16, 2009 at 6:01 PM, Kedar Mhaswade  wrote:
> This might be a n00b question, but is there an example that demonstrates how 
> one can collect DTrace output programmatically?
>
> For example, if I were interested in building a web interface for dtrace, how 
> should I go about it?

I've released a Ruby interface to DTrace, which you can use from a
Rails app, for instance. The interface covers both consuming DTrace
data and creating DTrace probes programmatically.

The interface docs are here:

  http://ruby-dtrace.rubyforge.org/

and the source lives on github, where you'll find an example of
integrating with Rails:

  http://github.com/chrisa/ruby-dtrace/tree/master

Hope that helps.

Chris.
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org


Re: [dtrace-discuss] C++ Applications with Dtrace

2009-01-16 Thread David Lutz
Hi Venkat,

Try running "::umausers umem_alloc_64" to see the top users of
that cache.  The output will be a list of stack traces and their
allocation stats.

David

- Original Message -
From: venkat 
Date: Friday, January 16, 2009 12:04 pm

> Hi David.
> 
> I am using mdb with libumem only
> 
> LD_PRELOAD=libumem.so UMEM_DEBUG=audit=30,maxverify=0,verbose  ./myservice
> 
> 
>   and while running my service i took core dump by gcore command 3 
> times with some time gap and appied dcmd commands 
> 
> while issue dcmd  ::umastat  i saw some moery allocations and use 
> sizes as increased , here find one cache name details 
>  
> 
> 
> 
> cachebuf  bufbuf memory
>  allocalloc
> namesizein use   total   in use
>  succeed  fail
> 
> umem_alloc_64  64 2463725024   3203072172506   0
> umem_alloc_64  64 2463725088   3211264417738   0
> umem_alloc_64  64 2497225088   32112641215782   0
> 
> 
> 
>If this  inceasing only causes for my problem. please tell 
> me how can i get stack for that cache .
> 
> 
> Thanks  in advance,
>  Venkat
> -- 

___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org


Re: [dtrace-discuss] C++ Applications with Dtrace

2009-01-16 Thread venkat
Hi David.

I am using mdb with libumem only

LD_PRELOAD=libumem.so UMEM_DEBUG=audit=30,maxverify=0,verbose  ./myservice


  and while running my service i took core dump by gcore command 3 times 
with some time gap and appied dcmd commands 

while issue dcmd  ::umastat  i saw some moery allocations and use sizes as 
increased , here find one cache name details 
 



cachebuf  bufbuf memory alloc   
 alloc
namesizein use   total   in use succeed 
 fail

umem_alloc_64  64 2463725024   3203072  172506 0
umem_alloc_64  64 2463725088   3211264  417738 0
umem_alloc_64  64 2497225088   3211264  1215782   0



   If this  inceasing only causes for my problem. please tell me how 
can i get stack for that cache .


Thanks  in advance,
 Venkat
-- 
This message posted from opensolaris.org
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org


Re: [dtrace-discuss] Programmatic interface to DTrace?

2009-01-16 Thread Nicolas Williams
On Fri, Jan 16, 2009 at 02:03:48PM -0500, Chip Bennett wrote:
> and for the C API (libdtrace):
> 
> http://dev.lrem.net/tcldtrace/wiki/LibDtrace

Oh, and there's a tantalizing link to a Tcl interface, not yet
populated, and an even more tantalizing link to what a TclDTrace script
would look like!
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org


Re: [dtrace-discuss] Programmatic interface to DTrace?

2009-01-16 Thread Kedar Mhaswade
Very nice. Thank you! This is what I was looking for.

Regards,
Kedar
-- 
This message posted from opensolaris.org
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org


Re: [dtrace-discuss] Programmatic interface to DTrace?

2009-01-16 Thread Chip Bennett
For a java API you might look at:

http://opensolaris.org/os/project/dtrace-chime/java_dtrace_api/

and for the C API (libdtrace):

http://dev.lrem.net/tcldtrace/wiki/LibDtrace
http://www.osdevcon.org/2008/files/osdevcon2008-petr.pdf

Chip

> -Original Message-
> From: dtrace-discuss-boun...@opensolaris.org [mailto:dtrace-discuss-
> boun...@opensolaris.org] On Behalf Of Kedar Mhaswade
> Sent: Friday, January 16, 2009 12:02 PM
> To: dtrace-discuss@opensolaris.org
> Subject: [dtrace-discuss] Programmatic interface to DTrace?
> 
> This might be a n00b question, but is there an example that
> demonstrates how one can collect DTrace output programmatically?
> 
> For example, if I were interested in building a web interface for
> dtrace, how should I go about it?
> 
> Thanks in advance,
> Kedar
> --
> This message posted from opensolaris.org
> ___
> dtrace-discuss mailing list
> dtrace-discuss@opensolaris.org


___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org


Re: [dtrace-discuss] Programmatic interface to DTrace?

2009-01-16 Thread Chip Bennett
Hi Kedar,

Are you familiar with Chime?

http://opensolaris.org/os/project/dtrace-chime/

Chip

> -Original Message-
> From: dtrace-discuss-boun...@opensolaris.org [mailto:dtrace-discuss-
> boun...@opensolaris.org] On Behalf Of Kedar Mhaswade
> Sent: Friday, January 16, 2009 12:02 PM
> To: dtrace-discuss@opensolaris.org
> Subject: [dtrace-discuss] Programmatic interface to DTrace?
> 
> This might be a n00b question, but is there an example that
> demonstrates how one can collect DTrace output programmatically?
> 
> For example, if I were interested in building a web interface for
> dtrace, how should I go about it?
> 
> Thanks in advance,
> Kedar
> --
> This message posted from opensolaris.org
> ___
> dtrace-discuss mailing list
> dtrace-discuss@opensolaris.org


___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org


[dtrace-discuss] Programmatic interface to DTrace?

2009-01-16 Thread Kedar Mhaswade
This might be a n00b question, but is there an example that demonstrates how 
one can collect DTrace output programmatically?

For example, if I were interested in building a web interface for dtrace, how 
should I go about it?

Thanks in advance,
Kedar
-- 
This message posted from opensolaris.org
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org


Re: [dtrace-discuss] C++ Applications with Dtrace

2009-01-16 Thread David Lutz
venkat  wrote:
>
> Hi ,
> 
>   I am using MDB to find memory leaks . i am getting Good report 
> with mdb.

Are you using mdb with libumem for this, or something else?

> 
> In one process , MDB showing zero memory leaks but process usage size 
> is increasing day by day .
>   How can we know reason for increasing size  . if any body know 
> to find this one please let me know

If you are using libumem, you could use the ::umausers dcmd to try to find
the biggest users of the allocator.  However, that only works for
allocations of less than 16k.  You can tell if you are making allocations
greater than 16k by checking for non-zero usage of umem_oversize,
as reported by ::umastat.

I recently blogged about finding memory leaks with libumem at
http://blogs.sun.com/dlutz/entry/memory_leak_detection_with_libumem
but only addressed the case where you actually lose track of memory
you allocated, not where you continually grow your memory foot
print but still maintain pointers to all of the memory.

HTH,
David

> 
>I have another process with same problem but 
> for this process MDb showing some memory leaks , the cause for that 
> leaks is i am allocating memory to some variable  when the process 
> startup only .  After that am just using those variables . in this 
> case  MDB showing only leaks at one time allocated variables ,   but 
> process usage size increasing.
> 
> Thanks in advance,
> Venkat
> -- 

___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org


[dtrace-discuss] One write is split into many physical IO (from result of fsrw.d )

2009-01-16 Thread Qihua Wu
Hi, All,

I have three questions about the output of fsrw.d
1: The write is to a shareplex queue(for oracle replication), but the write
is split into many many physical IO (I didn't paste all the disk_io here to
save space, but tons of such line contain "disk_io"). Does that means the
queue file is fragmented on disk? And it is also very strange as a writing
to a queue file resulted in disk_io on oracle file (the oracle file is QIO
file)

2: In the most right column, many lines are with value , what's the
meaning of it?

3: In the second column for disk_io. The value is like vxio127003, vxdmp100
and sd59. I used prtdiag and prtconf but can't find their definition. Where
can I find them?

sc-read   .  R 3608  0
/oracle/ULOOKUP/splex/vardir53_9i/rim/q_uhs_mig_part5+P+o.ULOOKUP-o.ULOOKUP.q
  fop_read.  R 3608  0
/oracle/ULOOKUP/splex/vardir53_9i/rim/q_uhs_mig_part5+P+o.ULOOKUP-o.ULOOKUP.q
sc-write  .  W 3608  0
/oracle/ULOOKUP/splex/vardir53_9i/rim/q_uhs_mig_part5+P+o.ULOOKUP-o.ULOOKUP.q
  fop_write   .  W 3608  0
/oracle/ULOOKUP/splex/vardir53_9i/rim/q_uhs_mig_part5+P+o.ULOOKUP-o.ULOOKUP.q
disk_io  vxio127003  W 8192  0 
disk_iovxdmp100  W 8192  0 
disk_iosd59  W 8192  0 
disk_io  vxio127003  W 8192  0 
disk_iovxdmp100  W 8192  0 
disk_iosd59  W 8192  0 
disk_io  vxio127000  R   131072  0
/oracle/ULOOKUP/data01/.ULOOKUP_index01_21.dbf::cdev:vxfs:
disk_io vxdmp36  R57344  0 
disk_iosd63  R57344  0 
disk_io vxdmp44  R65536  0 
disk_iosd61  R65536  0 
disk_io vxdmp92  R 8192  0 
disk_iosd67  R 8192  0 
disk_io  vxio127000  R   131072  0
/oracle/ULOOKUP/data01/.ULOOKUP_index01_21.dbf::cdev:vxfs:
disk_io vxdmp92  R57344  0 
disk_iosd67  R57344  0 
disk_io vxdmp68  R65536  0 
disk_iosd65  R65536  0 
disk_io vxdmp36  R 8192  0 
disk_iosd63  R 8192  0 
disk_io  vxio127000  R   131072  0
/oracle/ULOOKUP/data01/.ULOOKUP_index01_21.dbf::cdev:vxfs:
disk_io vxdmp36  R57344  0 
disk_iosd63  R57344  0 
disk_io vxdmp44  R65536  0 
disk_iosd61  R65536  0 
disk_io vxdmp92  R 8192  0 
disk_iosd67  R 8192  0 
disk_io  vxio127000  R   131072  0
/oracle/ULOOKUP/data01/.ULOOKUP_index01_21.dbf::cdev:vxfs:
disk_io vxdmp92  R57344  0 
disk_iosd67  R57344  0 
disk_io vxdmp68  R65536  0 
disk_iosd65  R65536  0 
disk_io vxdmp36  R 8192  0 
disk_iosd63  R 8192  0 
disk_io  vxio127000  R   131072  0
/oracle/ULOOKUP/data01/.ULOOKUP_index01_21.dbf::cdev:vxfs:
disk_io vxdmp36  R57344  0 
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org