In his post on dtrace.org Adam Leventhal summarizes the 10th anniversary celebration of the creation of ZFS. The post includes three videos on the subject, the first of which is with Matt Ahrens, co-creator of ZFS, who discusses the new stable ZFS interface designed for programmatic consumers of the solution. John Kennedy explains his work on the ZFS test suite, and Chris Siden of Delphix discusses his work on ZFS feature flags and Async Destroy, which allows datasets to be destroyed asynchronously in the background, which is especially helpful when gigantic datasets need to be erased, Leventhal observes.
(Get More Information . .)
Using the statistics generated by kstat and the tracings derived from DTrace, Brendan Gregg examines ZFS Adaptive Replacement Cache (ARC) activity in detail. In addition to calculating hit and miss rates, Gregg discusses other statistics including prefetch and metadata ratios, then writes about using tracing to observe information from the ARC – including who is using the ARC and why, ARC buffer sizes, the age of the ARC buffers, lock contention timings and eviction details. He points out that more can be traced as needed: ZFS with DTrace provides great performance and observability.
(Get More Information . .)
Interrupts are events delivered to CPUs, usually by external devices and can cause performance and observability problems for applications. Tim Cook's post explains the use of DTrace in identifying the source of interrupts and solving the performance problems caused when an interrupt "steals" a CPU from an application thread, halting its process while the interrupt is serviced. Cook calls this pinning (the interrupt will pin an application thread if the interrupt was delivered to a CPU on which an application was executing at the time). Cook cites several DTrace scripts to use in assessing the effects of pinning.
(Get More Information . .)
The blog post by samwan, "a dtrace example to troubleshoot 'cp-r' hang," shows how using opensnoop from the DTrace Toolkit located the particular file being read at a given moment, enabling the user to identify the pipe file on which the system was hung.
(Get More Information . .)
"Picking a non-C locale can hurt performance – something that has been known for many years. In this case, a GNU grep(1) bug inflated the translation overhead to slow down performance by a huge degree: up to 2000x. In short: leave LANG=C; aim DTrace at everything – even grep(1)." This is the recommendation Brendan Gregg arrives at in his post "2000x performance win." He recounts his experience in testing hypotheses framed to discover performance degradation in a production SmartOS cloud environment and the code samples involved with arriving at the conclusion above.
(Get More Information . .)
News and Solutions for Users of Solaris, Java and Oracle's Sun hardware products
Just the news you need, none of what you don't –
42,000+ Members – 24,000+ Articles Published since 1998