在最近一次对 Philippe Hanrigou 的采访中，讨论了关于 Ruby 监视和故障分析方面的议题。Philippe Hanrigou 指出，为什么在 Ruby 进程中断时，会有内存泄漏或者其他性能问题产生，这对于保持应用良好运行来说是很关键的问题。快速解决问题比认识到问题显得更为重要，特别是当一个业务服务碰到了问题，并且这个问题正在影响业务进程的时候。
相比基础的 Unix 工具，例如 gdb 或者 strace（用于显示程序调用另外一个程序的 syscall），DTrace是一个具有潜力并且很有用的工具。DTrace 起初是为 Solaris 开发的工具，允许低负载的对程序进行性能监控和跟踪。后来 DTrace 被迁移到其他操作系统上，最近迁移到了Mac OS X Leopard，该操作系统中的 DTrace 支持 Ruby 解释器。
Philippe 对 Linux 系统给出了一个建议的解决方案，目前 DTrace 不支持 Linux：
对于大多数社区的核心成员来说，值得付出时间和精力来推动 SystemTap 的前进。不幸的是，虽然有许多 Ruby 应用部署在 Linux 上，但 DTrace 并不支持 Linux 平台。由于许可证和其他没有解决的问题，实际上在可以预见的将来，把 DTrace 迁移到 Linux 平台上的可能性十分渺茫。在 Linux 上最接近于 DTrace 的代替者是 SystemTap，SystemTap 与 DTrace 的目的是一样的，然而不像 DTrace 那么成熟。实际上，对于用户空间运行程序的跟踪，SystemTap 仍然没有提供支持。
在JRuby上运行 Ruby 应用，使得开发者可以使用在 Java 平台上的那些性能监控和监视工具。 Ola Bini 在前些日子的一篇题目为"你的 Ruby 可以做这个么"博客文章中提出了这个看法，文中他使用JConsole（随 JDK 一起发行）来深入查看一个 JRuby 应用的运行情况。JConsole 可以附加在一个运行的 JVM 上 —— 使用 JMX—— 访问例如垃圾收集信息（generation sizes，collection runs 等），以及线程信息和所有其他通过 MBeans 暴露的信息。Philippe 还提到了其他用于处理内存泄漏的工具：
最终，当发生了内存泄漏时，常用的 Java 工具也可以帮忙解决问题。一个有用的技术是使用 jmap 得到堆信息，然后用 jhat 或者其他标准的 Java 堆信息分析器来检查堆信息。SAP 的内存分析器（SAP Memory Analyzer）也值得一试，Ola 认为这些工具非常有用。在 InfoQ 站点，最近对 SAP 或 IBM 的免费的内存分析器进行了一些讨论。
Philippe 最后表示他对Rubinius很感兴趣：
如果 Ruby 开发者可以容易的访问 Ruby 解释器，从而使用并扩展它的功能，那么最终构建一个 Ruby 的故障分析工具会简单很多。这就是为什么我认为象 Rubinius 这样的项目的成功从长期来看是将整个 Ruby 开发平台提升到一个新的高度的最佳方式。开发社区在 Rubinius 上投入多少时间和精力都是值得的。查看英文原文：Monitoring Ruby
译者简介： 曹云飞，西安交通大学计算机软件硕士。现就职于Ethos，热衷于计算机理论与应用技术的钻研，软件架构与敏捷开发，目前从事 consumer product 方面的工作。参与 InfoQ 中文站内容建设，请邮件至china-editorial[at]infoq.com。
注册/登录 InfoQ 发表评论