答：我们正在考虑使用各种方法继续提供 DTrace 方面的培训。目前，我们已将大量 BluePrint 风格的示例收录到《Solaris Dynamic Tracing Guid》（Solaris 动态跟踪指南）Answerbook 中，可通过 docs.sun.com 或 BigAdmin 网页找到此书。

如果您发现某些内容对 BluePrint 特别有用，或者您认为当前文档中缺少了什么内容，请通过电子邮件或 DTrace BigAdmin 论坛通知我们，我们将不胜感谢。其中是否有您所需的特定风格的信息？是否有简短的快速入门指南？或者，您是否需要更长一些的案例研究？

借助于此反馈，我们可以确定需要通过 BluePrints 创建的其他文档内容的最佳类型等信息。

返回页首

问：DTrace 与 truss 有什么不同之处？

答：DTrace 与 truss(1) 之间主要有以下两个差异：一个是 DTrace 信息收集方法的侵入性明显低于 truss；另一个是 DTrace 在很多不同的系统区域中提供系统范围的内省，而不仅仅是在进程中。我将在下面更详细地介绍这两种差异。

truss(1) 是一个实用程序，用于跟踪一个或多个进程的系统调用，并使用 proc(4) 文件系统作为收集信息的方法。/proc 是为传统调试实用程序设计的，因此，它建立在以下概念的基础上：停止进程，读取或写入其状态的各个位，然后再恢复该进程。truss 因而具有以下效果：从进程执行的每个系统调用返回时将停止进程，报告该结果，然后再继续执行该进程。

作为跟踪框架，DTrace 收集数据的操作方式略有不同。DTrace 对系统中的各种代码路径执行动态分析，并允许将数据记录到缓冲区中，以后会定期将这些数据复制到其用户端使用方以设置格式。因此，当代码流暂时停止先前执行的操作并进入 DTrace 时，不必像 /proc 那样使用强制方式“停止”线程或进程（当然，除非使用了 stop() 操作）。因此，DTrace 的探测器影响通常明显小于基于 /proc 的工具，如 truss(1)。

第二个主要差异是，DTrace 几乎允许观察系统中的所有内容，而不仅仅是进程模型。并且可以使用我们的跟踪语言 D 对 DTrace 进行编程，因此，您可以让 DTrace 执行几乎所有操作，而不仅仅是执行命令行开关所配置的一组行为。事实上，如果您阅读了我们的文档《Solaris Dynamic Tracing Guide》（Solaris 动态跟踪指南）的第 1 章，您就会发现，我们使用几行 D 实现了一个用于执行读取和写入操作的简单 truss 版本。

因此，虽然 DTrace 过程和系统调用提供程序允许您查看与 /proc 类似的内容，但您可以按所需的任何方式对这些内容进行编程，并且还可以将该信息与来自所有其他提供程序的信息合并在一起：i/o 信息、cpu 调度、vm 统计信息、用户函数调用以及所有其他信息。还可以使用 DTrace 查看系统范围的内容；查看每个进程、每个线程和每个文件的内容；或者查看可创建的任意数量的“视图”。

因此，DTrace 为您提供了一个通用的可编程工具，几乎可以解答有关系统的任何种类的问题。同时，truss(1) 仍可作为问题解决工具箱中的一个非常有价值的部分，当您遇到与某个进程的系统调用行为有关的特定问题时，您完全可以使用 truss 的内置功能来解决这些问题。

返回页首

问：我不知道应用程序出现了什么问题，问题似乎不是出在大量使用内存、io 或 cpu 上（根据 vmstat、iostat 和 mpstat）。
因此，要使用 Dtrace 查找瓶颈，应该从哪里入手呢？
我已经大致阅读了有关 sched、io 和 pid 提供程序的章节，但仍是一头雾水。对于我这个“迷途的羔羊”，您有什么具体的建议吗？

答：问题是：为什么应用程序不受其中一个物理资源的限制呢？理想情况下，应用程序（从性能角度看）应该只受一种物理资源的限制，以便只通过提高限制物理资源的性能，即可提高应用程序的性能。对于大多数应用程序来说，这意味着要求应用程序受 CPU 的限制。因此，如果应用程序没有受 CPU 的限制，那么问题就变成了：为什么会不受它的限制呢？要回答第一个问题，只需使用 sched 提供程序查明应用程序不受 CPU 限制的原因。请参见 sched 提供程序章节以了解更多详细信息，但下面为您提供了一个良好的开端：

# dtrace -n sched:::off-cpu'/execname == "my_app"/{@[ustack()] = count()}'

它会为您提供问题的答案，但也会带来新的问题；当然啦，也可以使用 DTrace 解答这些新问题。

附言：DTrace 的功能非常强大，完全超乎我的想像。要是我知道如何利用它的功能就好了。

谢谢您的夸奖，您的言外之意是，我们还需要提供更好的 DTrace“最佳做法”文档...


	
	返回页首
	 
	



  问：可以使用 DTrace 检测用户应用程序中的内存损坏和泄漏吗？如果可以，我应该将我的 Purify 许可证扔掉吗？
  
	
	答：执行上述操作时，更好的工具是 libumem(3LIB)，它是 Solaris 10 中新增的一个内存分配器。请参见 umem_debug(3MALLOC) 手册页并/或查看 Adam 博客中有关该主题的内容：http://blogs.sun.com/roller/page/ahl/?anchor=solaris_10_top_11_20

与 Purify 不同，libumem 在执行检查时只产生非常小的性能下降，因此，您可以在生产系统中选择将其启用。通过使用 gcore 和 ::findleaks，您可以在应用程序运行时查找其中的内存泄漏！  

DTrace 也在其中发挥了一些作用：使用 libumem 时，您可以对内存泄漏或内存损坏的根源作出假设，然后使用 DTrace 快速验证这种假设。有意思的是，我最近所做的恰恰就是这项工作：调试 dtrace(1M) 命令本身中的内存损坏问题。我首先使用 libumem 及其调试功能来尝试解决这一问题。结果表明，在访问已释放的结构时系统停止运行，并且我可能会获取释放发生位置的堆栈跟踪。这说明可能没有正确清理包含结构本身；通过使用 DTrace，我可以对这种假设进行验证，然后观察到确实错误地重用了包含结构。由于有了 libumem/DTrace 标记组，解决该问题所花的时间几乎比我写这段文章的时间还要短。用您自己的工具来调试您自己的错误，还有什么比这更惬意的了... ;)
	
	
	返回页首
	 
	



  问：我在一家银行担任安全分析师，我想知道 DTrace 在安全性方面有哪些作用。所有计算机上都运行 BSM，如果同时运行这两种工具，是否会使性能下降？
  
	
	答：DTrace 本身并不是一个安全工具，因此，它与 BSM 提供的功能类型完全无关。您当然可以在计算机上同时运行这两种工具，而不必担心会对性能造成严重影响。DTrace 仅使用动态分析，因此，没有使用 DTrace 的系统与没有安装它的系统是一样的：在禁用此工具的情况下，性能影响实际为零。而在使用 DTrace 时，只是有选择性地启用所需的分析，由于操作也是动态的，因此请求所产生的性能开销与要求 DTrace 所执行的操作成比例。

对于关注安全性的用户，您可能还希望阅读《Solaris Dynamic Tracing Guide》（Solaris 动态跟踪指南）中的 "Security"（安全性）一章（docs.sun.com 或 BigAdmin 中提供了该指南），其中介绍了 DTrace 自身的安全属性。对 DTrace 的访问是受限制的，您可以使用最少权限位通过 user_attr 工具为特定用户授予有限的访问权限，并且错误的 DTrace 程序不会造成系统崩溃。
	
	返回页首

Search BigAdmin

» Search the HCL

BigAdmin 专家

BigAdmin Subscriptions

BigAdmin Areas

BigAdmin Sun Center

BigAdmin Topics