Re:Strace – My Favourite Secret Weapon (2011)
by zwischenzug on Monday February 12, 2018 @02:26AM
(#16357110)
Whenever I've had to use it in prod (in heavy OLTP environments) the seriousness of the issue has always outweighed any performance concerns. Ditto tcpdump. Often it was used specifically to determine the cause of performance issues. In any case you generally only strace 1 process, and if your application stack depends on one process you're probably in other kinds of trouble... unless it's erlang :)
[ Parent
| on HN ]
Re:Strace – My Favourite Secret Weapon (2011)
by brendangregg on Monday February 12, 2018 @03:03AM
(#16357235)
It's not a choice between strace or nothing. It's a choice between strace, ftrace, perf, or eBPF -- and that's just the Linux builtins. Many low overhead addons can also do syscall tracing (sysdig, LTTng).
I often run ftrace, perf, and eBPF on our production instances for syscall tracing. If I ran strace, the instance would suddenly be very slow, and it would trigger Hysterix (and other) timeouts and be removed from the ASG and auto terminated. Our environment is fault-tolerant, so yes, we can run strace -- you just don't get much output, and the load vanishes from the instance you are looking at.
Re:Strace – My Favourite Secret Weapon (2011)
by Bromskloss on Monday February 12, 2018 @05:52AM
(#16357859)
Which of those alternatives are an option if the goal is to inspect and rewrite syscall arguments and return values, and do other things in between?