Linux Performance Analysis and Tools (opens in new tab)

(dtrace.org)

127 pointsjswanson12y ago24 comments

24 comments

Awesome talk, though the SystemTap coverage was oddly weak.

Saying 'SystemTap was was created when there weren't Solaris for Linux ports' is a little disingenuous. Linux had live kernel instrumentation with kprobes way before Sun debuted DTrace, and DTrace was deliberately licensed in a way to be incompatible with the Linux kernel.

If you want to see some actual useful production taps you can use right now on your Red Hat / CentOS box, check out http://sourceware.org/systemtap/wiki/WarStories

insaneirish12y ago

DTrace was deliberately licensed in a way to be incompatible with the Linux kernel.

This was commented on directly by Bryan Cantrill on HN [1]. You should also watch his "Fork Yeah!" [2] and "Corporate Open Source Anti-Patterns" [3] talks for full context.

[1]: https://news.ycombinator.com/item?id=4357507

[2]: http://www.youtube.com/watch?v=-zRN7XLCRhc

[3]: http://www.youtube.com/watch?v=NhgXQFk9noI

ehsanu112y ago

I want to point out a comment [1] apparently by the former chief open source evangelist, Danese Cooper [2], on the "Fork Yeah!" video contradicting Bryan Cantrill on this point. Here it is reproduced:

Lovely except it really was decided to explicitly make OpenSolaris incompatible with GPL. That was one of the design points of the CDDL. I was in that room, Bryan and you were not, but I know its fun to re-write history to suit your current politics. I pleaded with Sun to use a BSD family license or the GPL itself and they would consider neither because that would have allowed D-Trace to end up in Linux. You can claim otherwise all you want...this was the truth in 2005

[1] http://www.youtube.com/watch?v=-zRN7XLCRhc&lc=UEj5uH4rMafUnX... [2] http://en.wikipedia.org/wiki/Danese_Cooper

3 more replies

alanmackenzie12y ago

Great links.

evmar12y ago

I recently dove into this area in an attempt to find something like strace that didn't cost as much (as the slides mention, it's hundreds of times slower to run something under strace). It seems like dtrace can likely do what I want, but it doesn't sound reliable under linux yet. Does anyone know if the native linux profiling tools can be used to answer questions like "which files is my process accessing"?

As far as I found, various tools can trace syscalls and count them, but the critical thing strace adds is that it decodes the pointer parameters to syscalls into strings, something that e.g. "perf trace" doesn't seem to do.

joshbaptiste12y ago

Ktap was recently announced also https://github.com/ktap/ktap

justincormack12y ago

You could link your library to a passthrough libc that logs calls, if it is dynamically linked. There are various library hijacking solutions to make it easier. ptrace, that strace uses is necessarily slow (ktrace in eg NetBSD is much faster, the kernel does the tracing not userspace).

noerps12y ago

Try lsof for files accessed by process.

1amzave12y ago

Correct me if I'm wrong here, but I believe lsof can only display files held open at a given point in time (when you run lsof), no? So if a process opens a file, does something with it, and then immediately closes it, you're unlikely to be able to catch that with lsof unless you happen to run it at exactly the right time.

j / k navigate · click thread line to collapse