Re: [dtrace-discuss] Next finding about DTrace in MySQL
Hi Mikael, So with this limitation and the limitation that dtrace -G -s only applies to object files and not to libraries the only workaround I find is that one needs to build all object files in them same directory as the binary or can anyone come up with a different workaround. When Adam comes online later today I'll have a chat with him about these issues. One of us will pick them up. We'll contact you offline. Jon. ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
[dtrace-discuss] libdtrace and xcalls
Hi all I've got an app that periodically runs dtrace scripts through libdtrace and am seeing a good amount of xcalls from that. I understand why dtrace uses xcalls, so this is an expected behavior to a certain extent. But because my app repeats the scripts on an interval basis, the amount of xcalls is higher than I'd like it to be. Is there anything I can do to reduce that ? thanks Rafael ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] libdtrace and xcalls
I've got an app that periodically runs dtrace scripts through libdtrace and am seeing a good amount of xcalls from that. I understand why dtrace uses xcalls, so this is an expected behavior to a certain extent. But because my app repeats the scripts on an interval basis, the amount of xcalls is higher than I'd like it to be. Is there anything I can do to reduce that ? Yes: you can slow down your various rates (switchrate, aggrate, etc.) But the xcalls are probably more cosmetic than an actual problem: DTrace's xcalls execute very quickly, and are unlikely to be causing system-wide degradation. (This is true of essentially all xcalls -- xcalls are more likely to be a symptom of a larger problem than a problem in and of themselves.) Which raises a question: how many xcalls are you seeing, and have you used DTrace to make sure that they're all coming from DTrace? - Bryan -- Bryan Cantrill, Sun Microsystems Fishworks. http://blogs.sun.com/bmc ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] JAVA Hex address to symbol translation
I see the c/c++ calls symbols do appear on the stack back trace however for Java methods I see the hex addresses (e.g. 0x70e2322c 0x70c3cd98) - if I do pstack on the thread for this code (many times ) I may get the symbolic name (mangeled c++ name) for the Java method. On newer JVMs (1.4.2 and later I believe), the jstack action will perform the translation to symbolic Java method names. In some situations, you may need to change the default number of stack frames and bytes of symbolic Java data: jstack(frames, bytes) The symbolic translation is performed by a DTrace helper built into the JVM. There are some situations in which that helper is known to be deficient. On x86 platforms if the JVM is invoked with the -server option, you will not see the full stack trace. Further, if there are inlined functions, the helper may not pick those up whereas pstack(1) can. These are bugs that the Java team is aware of. I've never played with Java DTrace, but if the regular pid provider is anything to go by, this happens because the stack is recorded at the time the probe fires, but the matching of addresses to symbols happens somewhat later. If the application being traced has meanwhile disappeared, there's nothing to match to, and you get hex output. Java symbol name resolution does not work in the same way as ustack() for normal ELF symbols (i.e. C and C++). Adam -- Adam Leventhal, Fishworkshttp://blogs.sun.com/ahl ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] libdtrace and xcalls
On Tue, May 20, 2008 at 12:26 AM, Bryan Cantrill [EMAIL PROTECTED] wrote: I've got an app that periodically runs dtrace scripts through libdtrace and am seeing a good amount of xcalls from that. I understand why dtrace uses xcalls, so this is an expected behavior to a certain extent. But because my app repeats the scripts on an interval basis, the amount of xcalls is higher than I'd like it to be. Is there anything I can do to reduce that ? Yes: you can slow down your various rates (switchrate, aggrate, etc.) But the xcalls are probably more cosmetic than an actual problem: DTrace's xcalls execute very quickly, and are unlikely to be causing system-wide degradation. (This is true of essentially all xcalls -- xcalls are more likely to be a symptom of a larger problem than a problem in and of themselves.) Which raises a question: how many xcalls are you seeing, and have you used DTrace to make sure that they're all coming from DTrace? I'm not sure how many amount of xcalls is higher than you expect. You could find the root cause by: # dtrace -n 'xcalls [EMAIL PROTECTED]()]=count()]}' Thanks, -Aubrey ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
