It answers, or at least gives the definitive first clue behind a huge number of slow downs or apparent hangs, given how many of those are actually blocking resource waits or retry loops gone mad.
It's probably most useful to sysadmins working with binaries, or even if you do do have the source, it's usually a shorter path to the solution for any app/os interaction problem.
It's useful for certain classes of optimisation and tuning, because it will give timings and aggregate timings.
I'll use it for things as simple as "where is this program reading it's config files" - often useful when doco is poor and/or there are multiple config locations selected by conditional logic.
There's an "ltrace" as well, for share library tracing, although I've personally found that less useful - bugs that that shows are more likely to be code/logic problems rather that os/infrastructure interaction - which is to say, usually outside my job scope.
On commercial unix, the equivalent to strace is truss, and it's been around forever.
Like many, wirewhark, strace/truss are my go-to tools for a huge amount of troubleshooting.
It's probably most useful to sysadmins working with binaries, or even if you do do have the source, it's usually a shorter path to the solution for any app/os interaction problem.
It's useful for certain classes of optimisation and tuning, because it will give timings and aggregate timings.
I'll use it for things as simple as "where is this program reading it's config files" - often useful when doco is poor and/or there are multiple config locations selected by conditional logic.
There's an "ltrace" as well, for share library tracing, although I've personally found that less useful - bugs that that shows are more likely to be code/logic problems rather that os/infrastructure interaction - which is to say, usually outside my job scope.
On commercial unix, the equivalent to strace is truss, and it's been around forever.
Like many, wirewhark, strace/truss are my go-to tools for a huge amount of troubleshooting.