top | item 5848584

Linux Performance Analysis and Tools

127 points| jswanson | 12 years ago |dtrace.org | reply

24 comments

order
[+] nailer|12 years ago|reply
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

[+] evmar|12 years ago|reply
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.

[+] justincormack|12 years ago|reply
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).
[+] noerps|12 years ago|reply
Try lsof for files accessed by process.