BookFlocks

Brendan Gregg

Brendan Gregg

Who are you, and what do you do?


  • by (2013)

  • by , (2011)

  • by , , (2007)

I'm a senior performance architect at Netflix. I wrote Systems Performance (Prentice Hall, 2013), and co-authored DTrace (Prentice Hall, 2011) and Solaris Performance and Tools. I was previously a performance lead and kernel engineer at Sun Microsystems and later Oracle, where I developed the ZFS L2ARC, and worked on storage and network performance. I've invented and developed numerous performance analysis tools, which have been included in multiple operating systems. My recent work and passion is developing methodologies and visualizations for performance analysis, including for the Linux kernel.

What books have influenced you the most?

Earlier in my career, when I was doing system administration, it was Evi Nemeth's System Administration Handbooks. I had no shortage of formal reference documentation, namely man pages and vendor manuals. For some systems (VAX VMS), these could be measured by their shelf space in feet, or weight in pounds. For a senior system administrator, such documentation was great for the few times they needed it, where they could quickly locate the relevant pages. But for a junior administrator, it was intimidating and laborious. Evi Nemeth helped me understand the field, in a way that hundreds of pounds of vendor docs couldn't. She brought experience and expertise, shared opinions, selected the most important topics, and wrote in an accessible style. It was like having a mentor. You might say that this isn't really surprising, since vendors were expected to document everything formally -- which they are. But there isn't a rule to say they can't write such handbooks as well. They just generally didn't. Evi, meanwhile, did a great job.


by , , , (2010)

A little later, I was interested in taking on computer performance analysis and tuning as a profession, but it had the reputation of being the hardest topic one could do. This is because performance is subjective: there are no black and white answers like many other areas of IT, and it leans much more heavily on ones expertise. I wasn't sure if I had what it took, but I was curious to find out. Another professional suggested I read Solaris Internals 1st Edition, adding "you should understand all of that". Excellent, a challenge! This was, perhaps, the most deeply technical book one could read about operating systems, and had a reputation of being both excellent and mind breaking. I decided to not only read it, but not turn a page until I understood everything on that page. It took me 13 months, and some pages took several reads (Solaris 2.6 turnstiles!) before I understood it and could move on. (The book would since fall open to those pages, having damaged the spine.) It gave me an amazing basis from which to understand performance, and became a constant companion as I worked in the field. On a QANTAS flight to Brisbane I left that copy on the plane by accident, and spent the week dearly missing it, and realizing how important it was.


by , (2001)

I've read a lot of technical books. For a while I was teaching classes in APAC, and my students generally expected me to have read all the textbooks related to the topic I was teaching. Since I spent a lot of time in hotels, I had a lot of time to read them, too. Solaris Internals was more than just a book. It was the "open source" of the day: the closest any customer could get to reading the Solaris source code. And more than just code: kernel internals were explained in painstaking detail, including how it evolved and was developed. And another thing: it was a ton of new content, developed by experts. In the field of technical books, it is, sadly, rare. So many are reassemblies of existing documentation, written by people who aren't really the experts, and don't really bring much value to the project. Solaris Internals was the example of doing it Right.

I was so passionate about the book, that I became heavily involved in the 2nd Edition, and co-authored the companion volume. I've later written other books following the same principle: a deeply technical book, written by the experts, and bringing a lot of new value to an area that badly needs it.

A couple of other books in the same category would be Unix Internals by Uresh Vahalia, and Sun Performance and Tuning by Adrian Cockcroft. Uresh manages to bring you into the kernel development team and have you not only understand kernel internals, but understand the history and contemplate improvements. Adrian documented a lot of know how and methodologies, in a field that badly needed such guidance.


by (1996)

What book would you like to write?

I just finished the latest book I'd like to write: Systems Performance, published by Prentice Hall. What a relief to get that done! I have many ideas for future books, and growing pressure to document the undocumented, and will likely start another one soon.

In the past, I've written books that document a field for reference, and I've spent much effort and pages making it comprehensive and complete. But that's left less room for opinions and case studies (my DTrace book was over 1,100 pages, just to cover the field properly, so I really was out of room). In the future I'd like to focus less on writing a reference, and more on sharing expertise through stories and opinions. The books should be more fun to read, and write, although should be treated as an addition to other reference material.

There are books I'd like to see written: particularly around US tech corporate culture. I've read some books on Enron, which were fascinating, but I'd like to see more on DEC, HP, Sun, IBM, Microsoft, Google, Facebook, etc. It may be tricky for anyone to write honestly about these companies internal culture, while the companies still exist, so I'm not sure I'll ever see such books, but I wish I would.

Published on 2014-06-26

comments powered by Disqus