Skip to content

Instantly share code, notes, and snippets.

@SomeKittens

SomeKittens/Notes.md

Last active Apr 12, 2016
Embed
What would you like to do?
Notes from "Debugging Node in Production

What's slowing things down

Neflix makes this: https://github.com/restify/node-restify

Linux perf command: https://perf.wiki.kernel.org/index.php/Main_Page

  • Doesn't show our JS frames
  • V8 places symbols JIT
  • use node --perf_basic_prof_only_functions, woo
  • Can run in prod, negligble impact on perf
  • in v5, coming to v4

Now we've got a full stack trace with all the frames!

aaaand now we've got a bazillion traces/frames

Core dump

Things go wrong

  • Restart app, it keeps going
  • You now can take the coredump and debug
  • Node flag: --abort_on_uncaught_exception

tool: mdb (has JS plugins w/ mdb_v8, only works on Solaris)

Where (what code caused the crash) Why (did the project crash)

Need to name your functions shows you function name, file, line number can even pull out source code

Can pull out JS vars from memory

Core dumps give you complete process state

Memory leaks

Step 1: call Reed Hastings

Can generate core dump whenever you want: gcore

$gcore pgrep node<- backticks part of command (markdown ate 'em)

Can find all JS objs on heap with ::findjsobjects

So, take successive core dumps and compare object counts Look for growing things Find root obj (remember, can inspect actual objects via objhash::jsprint)

LOTTA OBJECTS can pipe & stuff

The whole goal of digging through memory leaks is to find the root object

objhash::findjsobjects -r <- finds objs with references to the hash

Tools to diff flame graphs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment