Unikernel Profiling from dom0 | Hacker News Reader

Unikernel Profiling from dom0

brendangregg.com

109 pointsyunong11 comments

So, background info. B. Gregg was at Sun before the evil Oracle acquisition. He quite literally wrote the book[0] on DTrace. Now he's at Netflix (i.e., he has as far as I can tell no vested interest in either that Docker/Solaris derivative [his interest is probably just getting great performance out anything that works rather than some plebian Mirage/unikernel vs on-the-metal BS we saw on Friday]). (Side-note, if you're reading this Mr. Gregg, your 2009 cheatsheet for DTrace[1] saved me countless hours on a production FreeBSD machine circa 2011. I owe you big.)

I've read his work on-and-off for a long time and there's little no to incendiary click-bait junk, or bias in most (if any) of what he publishes. Obviously he can't dedicate 60-hour resources a post-doc might, but he conducts most of his tests with rigor, and this blog post is no exception to the high-standards to which he presumably holds himself. I'd love to see Anil (one of the MirageOS leads (co-founder IIRC; pedigree - PhD from Imperial or Oxbridge)) comment. Either way, this is an example of how one should construct posts (I know we're not in academia, but there's no excuse for that absolutely abysmal post[2] made on Friday).

Thanks for raising the caliber of conversation, my good man.

[0] http://www.amazon.com/gp/product/0132091518/ref=as_li_ss_tl?...

[1] https://blogs.oracle.com/brendan/resource/DTrace-cheatsheet....

[2] https://www.joyent.com/blog/unikernels-are-unfit-for-product...

https://news.ycombinator.com/item?id=10953766 for the discussion

> Now he's at Netflix (i.e., he has as far as I can tell no vested interest in either that Docker/Solaris derivative

Well he probably has historical interest in Solaris, and generally any platform which supports dtrace, though he's been doing Linux work (http://www.brendangregg.com/linuxperf.html) for the last few years, given Netflix is mostly Linux-based with some FreeBSD (for the CDN nodes).

I couldn't agree more; Brendan Gregg is awesome. I finally created an account just to say this. His materials on Linux performance analysis and monitoring[0] are phenomenal. The analysis and observability maps he made are quite helpful to see the big picture and put specific tools in their proper context. I also particularly appreciate his materials on perf.

Maybe I'm being too much of a fanboy, but I appreciate good materials when I come across them.

[0] http://www.brendangregg.com/linuxperf.html

> I'd love to see Anil [...] comment.

Does a tweet count as commentary for you?

" Profiling MirageOS unikernels from a Xen dom0, an excellent and short howto -- http://www.brendangregg.com/blog/2016-01-27/unikernel-profil... " https://twitter.com/avsm/status/692396667576938497

Also, it's the Cambridge Computer Lab you're thinking of (at the University of Cambridge).

We also spoke about debugging (but not to this depth) on today's Docker Online Meetup about unikernels. We made the same points but Brendan's post is fantastic as he shows a worked example. There's a discussion thread [1] and there'll be a video of that webinar out soon too.

[1] https://devel.unikernel.org/t/docker-online-meetup-about-uni...

Thanks for the kind words, and I'm glad that cheatsheet was useful!

I'm sure if Anil or someone from the unikernel community is really interested in this, we'll see a better profiler soon (of either type). The initial goal should be to gather stacks for making into CPU flame graphs, which solve a ton of issues.

Note that this is in stark contrast from the post last week titled "Unikernels are unfit for production"[0]

One of that articles main ideas was:

"...the most profound reason that unikernels are unfit for production — and the reason that (to me, anyway) strikes unikernels through the heart when it comes to deploying anything real in production: Unikernels are entirely undebuggable."

[0] - https://news.ycombinator.com/item?id=10953766

Note that profiling and debugging are not the same. I agree that the other author did not make much research effort, but for me: profiling = snapshots of stack (r/o view), debugging = attaching interactive debugger (r/w view, patching breakpoints).

Either way, you can do both with unikernels.

Mr. Cantrill was just wrong.

There's nothing stopping you from attaching a debugger to a VM -- this is mighty handy for debugging boot loaders.

There's also nothing stopping you from including a runtime debugger interface in your unikernel, just like any other kernel that supports debugging.

+1 for another great bredangregg article. [2] https://www.joyent.com/blog/unikernels-are-unfit-for-product....

FYI, broken link.

Reply on news.ycombinator.com