• [Whole Web] [Node.js, PM2] Controlling runaway apps using pm2


    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.

    {
      "apps": [{
        "name": "App1",
        "script": "app1/server.js",
        "log_file": "/var/log/pm2/app1.log",
        "error_file": "/var/log/pm2/app1-err.log",
        "watch": true,
        "ignore_watch": ["node_modules"],
        "env": {
            "NODE_ENV": "production"
          },
        "instances": 0,
        "max_memory_restart": "16G",
        "max_restarts": 10
        },{
        "name": "App2",
        "script": "app2/server.js",
        "log_file": "/var/log/pm2/app2.log",
        "error_file": "/var/log/pm2/app2-err.log"
        }
      ]
    }
    instances

    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.

    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.

    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.

    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.

    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.

    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.

    max_memory_restart

    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.

    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.

    max_restart

    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.

    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.

    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.

     
  • 相关阅读:
    NJUPT_Wrj 个人训练实录
    图片保存本地,上传阿里云,保存该图片 在阿里云的 路径 到 本地数据库
    微信所有国家列表
    YII load()
    ab命令压力测试
    fatal: Could not read from remote repository
    JS获取URL中参数值的4种方法
    yii 生成 模型
    php子类是否自动调用父类构造函数
    自己实现一个简化版的SpringMVC框架
  • 原文地址:https://www.cnblogs.com/Answer1215/p/4502092.html
Copyright © 2020-2023  润新知