Strace是一个告诉您应用程序如何与操作系统交互的工具。

它通过告诉你应用程序使用什么操作系统调用以及调用它们的参数来做到这一点。

例如，您可以看到程序试图打开哪些文件，以及调用是否成功。

您可以使用此工具调试各种问题。例如，如果应用程序说它找不到你知道你已经安装的库，你strace会告诉你应用程序在哪里寻找那个文件。

而这只是冰山一角。

Strace列出它所应用的进程所执行的所有系统调用。如果您不知道系统调用是什么意思，那么您将无法从中获得很多好处。

然而，如果您的问题涉及到文件、路径或环境值，在有问题的程序上运行strace并将输出重定向到一个文件，然后在该文件中获取path/file/env字符串，这可能有助于您了解程序实际试图做什么，而不是您期望它做什么。

Strace是一种突出的工具，用于研究无法在调试器下运行这些程序的生产系统。具体来说，我们在以下两种情况下使用了strace:

Program foo seems to be in deadlock and has become unresponsive. This could be a target for gdb; however, we haven't always had the source code or sometimes were dealing with scripted languages that weren't straight-forward to run under a debugger. In this case, you run strace on an already running program and you will get the list of system calls being made. This is particularly useful if you are investigating a client/server application or an application that interacts with a database Investigating why a program is slow. In particular, we had just moved to a new distributed file system and the new throughput of the system was very slow. You can specify strace with the '-T' option which will tell you how much time was spent in each system call. This helped to determine why the file system was causing things to slow down.

有关使用strace进行分析的示例，请参阅我对这个问题的回答。

我一直使用strace来调试权限问题。技巧是这样的:

$ strace -e trace=open,stat,read,write gnome-calculator

其中gnome-calculator是您想要运行的命令。

下面是我如何使用strace挖掘网站的一些例子。希望这对你有帮助。

检查时间到第一个字节，如下所示:

time php index.php > timeTrace.txt

看看有多少百分比的动作在做什么。大量的lstat和fstat可能表明是时候清理缓存了:

strace -s 200 -c php index.php > traceLstat.txt

输出trace.txt，以便您可以准确地看到正在进行的调用。

strace -Tt -o Fulltrace.txt php index.php

使用它来检查是否有东西在0.1到0.9秒之间加载:

cat Fulltrace.txt | grep "[<]0.[1-9]" > traceSlowest.txt

查看strace中捕获了哪些丢失的文件或目录。这将输出很多涉及我们系统的东西-唯一相关的位涉及客户的文件:

strace -vv php index.php 2>&1 | sed -n '/= -1/p' > traceFailures.txt

Strace可以用作调试工具，也可以用作原语分析器。

As a debugger, you can see how given system calls were called, executed and what they return. This is very important, as it allows you to see not only that a program failed, but WHY a program failed. Usually it's just a result of lousy coding not catching all the possible outcomes of a program. Other times it's just hardcoded paths to files. Without strace you get to guess what went wrong where and how. With strace you get a breakdown of a syscall, usually just looking at a return value tells you a lot.

剖析是另一个用途。您可以使用它来分别计时每个系统调用的执行，或者作为一个聚合。虽然这可能不足以解决您的问题，但至少可以大大缩小潜在嫌疑人的范围。如果您在单个文件上看到大量的fopen/close对，那么您可能在每次执行循环时都不必要地打开和关闭文件，而不是在循环之外打开和关闭它。

Ltrace是strace的近亲，也非常有用。你必须学会区分你的瓶颈在哪里。如果执行的总时间是8秒，而你在系统调用上只花了0.05秒，那么对程序进行分段不会有什么好处，问题出在你的代码中，这通常是一个逻辑问题，或者程序实际上需要花那么长时间来运行。

The biggest problem with strace/ltrace is reading their output. If you don't know how the calls are made, or at least the names of syscalls/functions, it's going to be difficult to decipher the meaning. Knowing what the functions return can also be very beneficial, especially for different error codes. While it's a pain to decipher, they sometimes really return a pearl of knowledge; once I saw a situation where I ran out of inodes, but not out of free space, thus all the usual utilities didn't give me any warning, I just couldn't make a new file. Reading the error code from strace's output pointed me in the right direction.