Re: [dtrace-discuss] Can I pass a parameter to Dtrace script as a part of function name?
$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?
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
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
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
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
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
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?
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?
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
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
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?
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?
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?
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?
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?
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
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 )
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