Monitoring Ruby

Posted by Werner Schuster on Dec 14, 2007

Sections

Development,

Architecture & Design

Topics

Ruby ,

Performance & Scalability ,

Debugging

Tags

DTrace ,

JRuby

A recent interview with Philippe Hanrigou goes into the topic of monitoring and troubleshooting Ruby. Figuring out why a Ruby process fails, has a memory leak or some performance issue, is important to keep applications running. Figuring this out fast is even more important, particularly if a production server has developed a problem and this is now impeding business.

Next to the basic Unix tools such as gdb or strace (a tool that shows the syscalls a program made by a program), DTrace is mentioned as a potentially useful tool. DTrace, tool that allows low-overhead profiling of and tracing of programs, was originally developed for Solaris. It has since been ported to and shipped with other systems, most recently to Mac OS X Leopard which includes DTrace support for the Ruby interpreter.

Philippe suggests a solution for Linux, a system where DTrace isn't supported yet:

For the most hardcore members of the community it might be worth investing some time and energy to help push SystemTap forward. Unfortunately, while many Ruby applications are deployed on Linux, DTrace is not available on this platform. Due to licensing and unresolved issues there is actually very little chance that DTrace will ever be ported to Linux in the foreseeable future. The closest alternative to DTrace on Linux is SystemTap, which shares the same objectives but is not quite as mature yet. In particular, SystemTap still does not seem to provide support for traces in user space programs.

Running Ruby apps on JRuby gives developers access to the host of profiling and monitoring tools available for the Java platform. Ola Bini mentioned this as an advantage some time ago in a blog post titled "Can your Ruby do this", where he uses JConsole (shipped with JDKs) to look inside a JRuby app. JConsole can attach to a running JVM and - using JMX - access information such as Garbage Collection information (generation sizes, collection runs, etc.), thread information and all other information exposed through MBeans. Philippe also mentions another tool to deal with memory leaks:

Finally, when it comes to memory leaks, the usual Java tools also come to the rescue. A useful technique is to get a heap dump with jmap and then inspect it with jhat or any standard Java heap dump analyzer. Give the SAP Memory Analyzer a try—Ola had a great experience with it.

InfoQ recently discussed some free memory analyzer tools from SAP or IBM.

Philippe finishes by expressing his interest in Rubinius:

Finally building troubleshooting tools for Ruby would be a lot easier if any Ruby developer could easily access the Ruby interpreter to instrument and extend it. This is why I consider the success of a project such as Rubinius to be the best way for take the platform to a whole new level in the long term. Any time and effort that the community invest in Rubinius will be well spent.

• Older >