Name: Controlling runaway apps using pm2
Uploaded: 2015-04-19T18:39:27-05:00
Description: This video shows how to enable features in your pm2 config file that allow you to prevent runaway apps from bringing your server down. Setting max memory used, number of running processes allowed and maximum restart attempts are all covered.

This video shows how to enable features in your pm2 config file that allow you to prevent runaway apps from bringing your server down. Setting max memory used, number of running processes allowed and maximum restart attempts are all covered.

https://app.egghead.io/api/v1/lessons/node-js-controlling-runaway-apps-using-pm2/subtitles

Controlling runaway apps using pm2

[00:02] There are three other options I want to cover real quickly before we wrap this up, and they're done inside the config file again.

[00:10] The first one I want to cover is the instances object. What instances will do is spin up the number of processes defined here. If we set this to zero, PM2 is going to spin up one process for every CPU you have in your system.

[00:31] If you want a little finer control of that, you can put in two, four, six, seven, whatever number you'd like to see as far as the number of running processes. The reason the instances option is so cool is because it allows you to do rolling restarts, and graceful reloads of your app.

[00:48] In the event that you deploy code and issue a reload command to PM2, what's going to happen is it's not going to kill any active connections.

[00:59] As those connections close or go away, it will stop them and bring up new processes that contain your new code. What essentially happens there is that anyone who's currently using your website during that reload command won't be disconnected.

[01:16] Their session will stay, and they'll be allowed to finish whatever operation they were on without having their process killed. This creates a much more professional experience for your users.

[01:30] Another cool option that may be handy for you in times of desperate need is the max memory restart. You can use this...let's say that you've been profiling your note app, and you've noticed that if you get above eight gig of memory utilization, your app starts behaving very sporadic and is prone to crash. What you can actually tell PM2 to do is just when you get to eight gig of memory utilization, to go ahead and restart your app.

[02:03] Clearly, this isn't something that you want to depend on, or it doesn't...you don't want this to be your everyday running configuration. If you've got a bug that you just haven't been able to find, and you've got to keep your site up for your customers, this is going to help you out.

[02:17] The last one we'll cover is max restarts, which is probably a good one to use in combination with max memory restart. What this will do is tell PM2 to only restart your app the number of times listed here, for our example, 10 times.

[02:34] After 10 times, if your app crashes, PM2 is going to bring that down or it's going to leave it in erred state and it won't attempt to restart it until you stop and restart the entire PM2 process.

[02:48] This is just like a safety valve, and it's going to keep a rogue app on your system from consuming all your system resources by continually restarting. When it hits that max number, PM2 will just let it die and save your system until you can come in and manually intervene.

[03:07] The last thing I have to say about this, is we've built out multiple apps suing a configuration file. We've learned how to define each one differently so that each one can have its own unique characteristics.

[03:18] The coolest thing about all of this is we've done this inside of the config file, and that config file can now be added to your repo, where it gets all the benefits of source control, version control, and it can be managed as code with the rest of your code base.

Controlling runaway apps using pm2

Share this video with your friends