- Capabilities
- Strategy
- Checklist
- Providers
- Scripts
- Case Studies
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Checklist
Consider Table 9-1 a checklist of application issue types that can be examined using DTrace. This is similar to the checklist in Chapter 8 but is in terms of applications rather than the language.
Table 9-1. Applications Checklist
|
Issue |
Description |
|
on-CPU time |
An application is hot on-CPU, showing high %CPU in top(1) or prstat(1M). DTrace can identify the reason by sampling user stack traces with the profile provider and by tracing application functions with vtime-stamps. Reasons for high on-CPU time may include the following:
The actual make-up of CPU time, whether it is cycles on core (for example, for the Arithmetic Logic Unit) or cycles while stalled (for example, waiting for memory bus I/O) can be investigated further using the DTrace cpc provider, if available. |
|
off-CPU time |
Applications will spend time off-CPU while waiting for I/O, waiting for locks (not spinning), and while waiting to be dispatched on a CPU after returning to the ready to run state. These events can be examined and timed with DTrace, such as by using the sched provider to look at thread events. Time off-CPU during I/O, especially disk or network I/O, is a common cause of performance issues (for example, an application performing file system reads served by slow disks, or a DNS lookup during client login, waiting on network I/O to the DNS server). When interpreting off-CPU time, it is important to differentiate between time spent off-CPU because of the following:
Applications may spend most of their time waiting for work to do, which is not typically a problem. |
|
Volume |
Applications may be calling a particular function or code path too frequently; this is the simplest type of issue to DTrace: frequency count function calls. Examining function arguments may identify other inefficiencies, such as performing I/O with small byte sizes when larger sizes should be possible. |
|
Locks |
Waiting on locks can occur both on-CPU (spin) and off-CPU (wait). Locks are used for synchronization of multithreaded applications and, when poorly used, can cause application latency and thread serialization. Use DTrace to examine lock usage using the plockstat provider if available or using pid or profile. |
|
Memory Allocation |
Memory allocation can be examined in situations when applications consume excessive amounts of memory. Calls to manage memory (such as malloc()) can be traced, along with entry and return arguments. |
|
Errors |
Applications can encounter errors in their own code and from system libraries and system calls that they execute. Encountering errors is normal for software, which should be written to handle them correctly. However, it is possible that errors are being encountered but not handled correctly by the application. DTrace can be used to examine whether errors are occurring and, if so, their origin. |