5 ms·
The process that kept dying: A memory leak murder mystery
- hsag 2y ago[dead]
- Charon77 2y agoIn my team we actually had to do performance test every time we update our libraries, and never auto update.
- luketheobscure 2y agoWe certainly do performance tests, and we also don't auto-update. The issue here was it was a slow leak, so it took time and significant load for the pattern of errors to present itself.
- oneepic 2y agoI'd like to read this article but keep getting ERR_TOO_MANY_REDIRECTS. Sorry, your site seems broken.
- luketheobscure 2y agoThank you so much for letting me know. Tried out cloudflare this morning, rolling it back.
- johnnyapol 2y agoIs anyone else getting a redirect loop when trying the link? At first I was thinking it had to do with my Firefox settings to force HTTPS but even just: curl -L lukedeniston.com/memory-leak-mystery > curl: (47) Maximum (50) redirects followed isn't working.
- luketheobscure 2y agoIt's me... tried out cloudflare this morning. Bad timing.
- chmod775 2y agoThe site is broken right now, but I read this when it was first submitted some time ago. Contrary to what the title would suggest, it's about finding a mundane JS memory leak in moment.js by attaching the chrome inspector to node. There's no out-of-the-ordinary tale here and there's certainly little mystery. The article might be useful if you've never done it before and need some pointers.
- throw156754228 2y ago>The NODE_OPTIONS were only applying to the yarn process, not the underlying Next.js server that was being invoked by yarn. Doesn't make sense. All child processes should get that env var.