This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
David Boreham wrote:<slaps forehead> I did wonder about that but I figured 'no, it couldn't be that simple'. But surely we need this documented, otherwise anyone using LKET will have the same question ? I'd be happy to update the man page if that'd help.
I ever thought of turning on fork/execve events by default, but finally I left it to the users to decide whether they want to capture such events. Do you think we should turn on fork/execve capture by default since they have a negligible overhead?
Well I did assume that those probes were added by default, since I could
see tht they were required by b2a. I would say yes, with perhaps a flag
to disable them for situations where enabling them would not be appropriate.
It seems that it will be more convenient if lket turns on tracing process fork/execve events by default. But there is no way to turn off an already turned-on probe. The trouble is that if user script turns on process fork/execve again, then LKET will be trigger twice every time fork or execve is called.
So my suggestion is that we document clearly that fork/execve have already be turned on by default, and we change the probe alias of addevent.process.fork/addevent.process.execve to something like lketinternal.process.fork/lketinternal.process.execve so that a probe point like "addevent.*" in user stp script won't trigger fork/execve once again.
probe begin { stoptrace_fork = 1 stoptrace_exec = 1 } probe addevent.iosyscall, addevent.scsi {}
I don't remember that LKET ever wrote event names into lket.out. Only group id and hook id is written. Can you paste here a snippet of the output?
Sure, I'm reading the man page here : http://sourceware.org/systemtap/man5/lket-b2a.1.html (cvs has the same version). I see output like this:
10.24319 APPNAME: sshd PID:7203 CPU:3 HOOKGRP:2 HOOKID:2 syscall:write,
that appears to show the event name : "syscall:write". But when I run b2a I get output like this:
73.232758 APPNAME: mime.browse PID:19697 CPU:0 HOOKGRP:9 HOOKID:7 fd:9,buff_addr:-1208643584,count:3773,
After a few hours working with these files I do know that 9,7 is 'write' but wouldn't it be
handy to emit the event name in the file ? (actually there's not much need IMHO for the
group and hook ids because they're not human-readable anyway).
Yes. syscall:write is only the output while not the event name. I also think that "9,7" is hard to read. So there are two options:
[...]
I also updated the man page and SystemTap website for these changes. Thanks for your comments and suggestions.Couple of reasons for postprocessing in MySQL:
Yeah I don't disagree, I'm just reporting my user experience. Actually I'm supposedly a database expert , but I mainly work with their internal implementation rather than actually _using_ them ;)
This example will generate top 10 most frequently syscalls
Examples would be good. I can probably generate some.
The first thing I need to do is make a script that invokes
mysql in an automated fashion, avoiding all that show databases; use xxxxx; stuff.
It should just pick the most recent one.
It will be great if you can add your store procedures/scripts into LKET. People will find lket easier to use if we provides as much as more the store procedures/shell scripts for post-processing.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |