Systems Performance: Enterprise and the Cloud First Edition

Long ago, the prerequisite UNIX performance book was Adrian Cockcroft's 1994 classic, Sun Performance and Tuning: Sparc & Solaris, later updated in 1998 as Java and the Internet. As Solaris evolved to include the invaluable DTrace observability features, new essential performance references have been published, such as Solaris Performance and Tools: DTrace and MDB Techniques for Solaris 10 and OpenSolaris (2006) by McDougal, Mauro, and Gregg, and DTrace: Dynamic Tracing in Oracle Solaris, Mac OS X and FreeBSD (2011), also by Mauro and Gregg.Much has occurred in Solaris Land since those books appeared, notably Oracle's acquisition of Sun Microsystems in 2010 and the demise of the OpenSolaris community. But operating system technologies have continued to improve markedly in recent years, driven by stunning advances in multicore processor architecture, virtualization, and the massive scalability requirements of cloud computing.A new performance reference was needed, and I eagerly waited for something that thoroughly covered modern, distributed computing performance issues from the ground up. Well, there's a new classic now, authored yet again by Brendan Gregg, former Solaris kernel engineer at Sun and now Lead Performance Engineer at Joyent.Systems Performance: Enterprise and the Cloud is a modern, very comprehensive guide to general system performance principles and practices, as well as a highly detailed reference for specific UNIX and Linux observability tools used to examine and diagnose operating system behaviour. It provides thorough definitions of terms, explains performance diagnostic Best Practices and "Worst Practices" (called "anti-methods"), and covers key observability tools including DTrace, SystemTap, and all the traditional UNIX utilities like vmstat, ps, iostat, and many others.The book focuses on operating system performance principles and expands on these with respect to Linux (Ubuntu, Fedora, and CentOS are cited), and to Solaris and its derivatives [1]; it is not directed at any one OS so it is extremely useful as a broad performance reference.The author goes beyond the intricacies of performance analysis and shows how to interpret and visualize statistical information gathered from the observability tools. It's often difficult to extract understanding from voluminous rows of text output, and techniques are provided to assist with summarizing, visualizing, and interpreting the performance data.Gregg includes myriad useful references from the system performance literature, including a "Who's Who" of contributors to this great body of diagnostic tools and methods.This outstanding book should be required reading for UNIX and Linux system administrators as well as anyone charged with diagnosing OS performance issues. Moreover, the book can easily serve as a textbook for a graduate level course in operating systems [2].[1] Solaris 11, of course, and Joyent's SmartOS (developed from OpenSolaris)[2] Gregg has taught system performance seminars for many years; I have also taught such courses...this book would be perfect for the OS component of an advanced CS curriculum.

As expected, this book is primarily for the Linux or Solaris System Administrators. But, I found it very useful in understanding how to measure and diagnose issues with CPU, memory, storage, and networking.Gregg promotes his USE methodology for investigating performance issues:Utilisation—how much of a resource is being used?Saturation—is the resource fully utilised?Errors—are there errors concerning the resource? Some resource managers fail requests rather than queue themHe provides a whole chapter on how he solved a difficult performance problem through the use of this method.Gregg also covers benchmarking:"Benchmarking is surprisingly difficult to do well, with many opportunities for mistakes and oversights."Gregg is a big fan of dtrace and provides numerous scripts throughout the book, and in the appendix.I will have to read the book again sometime soon in order to pick more ideas about performance tuning and diagnosis.

This book explains methodology and approaches to systems performance analisys. Examples of using tools, some tips and tricks also included,If you are good at linux(or solaris) and interested in system and application performance, tracing and profiling, but you have some messy knowledge about this things - this book is for you.It is not about system administration, but it's between programming and adminstration.Reading this book and feel like i'm breaking through the wall of ignorance. Last time experienced similar feelings when reading Andrew Tanenbaum's books. This one is less theoretical, more practical.Strongly recommended.

Systems Performance shines best as a reference guide for experienced performance engineers who may be working in new areas or want to discover tools and methods in their own areas they may not have been exposed to yet. . In that way I find it does a great job of covering a very wide range of tools and discussing how Solaris/Linux works and how to fix the patient. The methods and methodology are quite practical and provably useful. It is not however a book on software development principles or architecture design nor is it a good introduction to performance engineering by itself. In my opinion, there's not a lot of tips or discussion for the reader trying to diagnose n-tier systems or enough emphasis on how systems work from one thread to n-threads in those systems but he does touch them, like vermouth on a very dry martini should be.Another reviewer called Gregg's methods "pseudo-scientific" but I don't think scientific vs. non-scientific is even slightly useful to describe this book. In medicine we have medical research, and medical practice. The two are done in completely different ways (and thank goodness for that!) but few call the General Practitioner's methods "pseudo scientific." Instead they call it the Doctor's work an "art and a practice" which is in fact the very best we can get. So too is performance engineering in working systems.There is at least one Linux foible though. Gregg's description of how the fork() call works is a bug (er, um, feature?) unique to Solaris which may cause memory starvation if forking many small processes from a large JVM. It doesn't happen in any other Unix/Linux I know of. However, we must forgive him for the otherwise excellent and comprehensive reference work.One star was deducted because the book binding failed as soon as I opened it and several pages from the introduction became unglued.