On my 8GB RAM MacBook, Node.js will set its heap size to 2GB. You can see what is set on your application with: const v8 = require ( 'v8' ) const GB ` ) In short, latest versions of Node.js will automatically set it based on the available memory, e.g., it doesn't use all of it - but you can still shrink or expand it with -max-old-space-size according to your needs, if you know what you're doing. You can find a gist, linking to a StackOverflow thread, a GitHub issue, some very useful pieces on debugging memory leaks and optimizing memory usage, but no official documentation piece detailing how it's determined by default. about that - it's ridiculously hard to find official documentation on how Node.js configures its v8 heap size. In one of my first client gigs where I delivered a Node.js application, when the time came to deploy, my final recommendation was to use 8GB RAM in all instances running Node.js, and use ridiculously high setting for -max-old-space-size, and pm2 in cluster mode, so that individual instances could die and restart automatically. And it's embarassingly easy to shoot yourself in the foot and make it like memory even more. The first thing you learn when taking Node.js applications to production, is that it likes memory, a lot. That doesn't mean it's not without its challenges. JavaScript became a universal language, one I could use not only for the browser but also for nearly all my backend needs. That was when I realized SSR applications were the future - they made things easier, faster, reduced friction and context switching in development. That was when I realized Node.js had matured and was good enough for running applications in production.
Looking back, it's been now over five years since I left Python for JavaScript. You're looking at an individual entry - check out the index for more! Monitoring Node.js Performance
0 kommentar(er)
