This chapter is from the book
Strategy
To get started using DTrace to examine applications, follow these steps (the target of each step is in bold):
- Try the DTrace one-liners and scripts listed in the sections that follow and from the other chapters in the "See Also" section (which includes disk, file system, and network I/O).
- In addition to those DTrace tools, familiarize yourself with any existing application logs and statistics that are available and also by any add-ons. (For example, before diving into Mozilla Firefox performance, try add-ons for performance analysis.) The information that these retrieve can show what is useful to investigate further with DTrace.
- Check whether any application USDT providers are available (for example, the mozilla provider for Mozilla Firefox).
- Examine application behavior using the syscall provider, especially if the application has a high system CPU time. This is often an effective way to get a high-level picture of what the application is doing by examining what it is requesting the kernel to do. System call entry arguments and return errors can be examined for troubleshooting issues, and system call latency can be examined for performance analysis.
- Examine application behavior in the context of system resources, such as CPUs, disks, file systems, and network interfaces. Refer to the appropriate chapter in this book.
- Write tools to generate known workloads, such as performing a client transaction. It can be extremely helpful to have a known workload to refer to while developing DTrace scripts.
- Familiarize yourself with application internals. Sources may include application documentation and source code, if available. DTrace can also be used to learn the internals of an application, such as by examining stack traces whenever the application performs I/O (see the example at the start of this chapter).
- Use a language provider to trace application code execution, if one exists and is available (for example, perl). See Chapter 8, Languages.
- Use the pid provider to trace the internals of the application software and libraries it uses, referring to the source code if available. Write scripts to examine higher-level details first (operation counts), and drill down deeper into areas of interest.