pm2實踐指南

介紹

PM2是一個帶有負載均衡功能的Node應用的進程管理器。PM2能夠利用服務器上的全部CPU，並保證進程永遠都活着，0秒的重載，部署管理多個Node項目。PM2是Node線上部署完美的管理工具

基本指令

npm install pm2 -g ： 全局安裝。
pm2 start app.js ： 啓動服務，入口文件是app.js。
pm2 start app.js -i [n] --name [name] ： 啓動n個進程，名字命名爲name。
npm restart  [name or id] ： 重啓服務。
npm reload  [name or id] ： 和rastart功能相同，可是能夠實現0s的無縫銜接；若是有nginx的使用經驗，能夠
對比nginx reload指令。
pm2 start app.js --max_memory_restart 1024M ： 當內存超過1024M時自動重啓。 若是工程中有比較棘手的內
存泄露問題，這個算是一個折中方案。
pm2 monit ： 對服務進行監控。
複製代碼

查看服務進程數

至於要啓動幾個進程，能夠經過服務器的內核數進行肯定，幾個內核就啓動幾個服務。指令以下：

# 查看物理CPU個數
  cat /proc/cpuinfo| grep "physical id" | sort| uniq | wc -l
  # 查看每一個物理CPU中core的個數(即核數)
  cat /proc/cpuinfo| grep "cpu cores"| uniq
  # 查看邏輯CPU的個數
  cat /proc/cpuinfo| grep "processor"| wc -l
複製代碼

固然能夠啓動多個端口，一個端口號對應一個服務，這樣的話就須要nignx來作負載均衡了。

fork與cluster啓動模式

開發環境中多以fork的方式啓動，生產環境中多用cluster方式啓動

上面的示例圖中能夠看一「watching」一項，這個項默認是disabled，能夠經過以下命令開啓

pm2 start app.js --name m --watch
複製代碼

建議：這個適合在開發時用，能夠省很多時間，生產環境下最好不要用

一、cluster是fork的派生，cluster支持全部cluster擁有的特性；

二、fork不支持socket地址端口複用，cluster支持地址端口複用。由於只有node的cluster模塊支持socket選項SO_REUSEADDR；

fork不能夠啓動多個實例進程，cluster能夠啓動多個實例。但node的child_process.fork是能夠實現啓動多個進程的，可是爲何沒有實現呢？就我的理解，node多爲提供網絡服務，啓動多個實例須要地址端口複用，此時即可使用cluster模式實現，但fork模式並不支持地址端口複用，多實例進程啓動會產生異常錯誤。但對於常駐任務腳本而言，不須要提供網絡服務，此時多進程啓動能夠實現，同時也提升了任務處理效率。對於上述需求，能夠兩種方式實現，一是配置app0,app1,app2方式啓動多個進程，二是經過應用實例自身調用child_process.fork多進程編程實現；

fork模式能夠應用於其餘語言，如php，python，perl，ruby，bash，coffee， 而cluster只能應用於node;

fork不支持定時重啓，cluster支持定時重啓。定時重啓也就是配置中的cron_restart配置項。

pm2的監控

pm2的監控有兩種方式：

cli方式監控

pm2 monit是專門用來監控的命令，監控項包括cpu與內存,缺點monit展現內容太過粗糙，不夠詳細

pm2 list展現當前全部pm2的管理項目

能夠查看出每一個進程的運行狀態。

若是須要更詳細的監控內容，對於cli而言通常都是能夠實現的。

這種監控方式的缺點：

一、不夠直觀，須要本身去執行命令並分析結果；

二、不便於多臺服務器的應用監控管理；

日誌問題

日誌系統對於任意應用而言，一般都是必不可少的一個輔助功能。pm2的相關文件默認存放於$HOME/.pm2/目錄下，其日誌主要有兩類：

一、 pm2自身的日誌，存放於$HOME/.pm2/pm2.log；

二、 pm2所管理的應用的日誌，存放於$HOME/.pm2/logs/目錄下，標準誰出日誌存放於${APP_NAME}_out.log，標準錯誤日誌存放於${APP_NAME}_error.log；

這裏之因此把日誌單獨說明一下是由於，若是程序開發不嚴謹，爲了調試程序，致使應用產生大量標準輸出，使服務器自己記錄大量的日誌，致使服務磁盤滿載問題。通常而言，pm2管理的應用自己都有本身日誌系統，因此對於這種沒必要要的輸出內容需禁用日誌，重定向到/dev/null。

與crontab比較，也有相似狀況，crontab自身日誌，與其管理的應用自己的輸出。應用腳本輸出必定須要重定向到/dev/null，由於該輸出內容會以郵件的形式發送給用戶，內容存儲在郵件文件，會產生意向不到的結果，或會致使腳本壓根不被執行。

高級用法

pm2支持配置文件啓動：

pm2 pm2： 生成配置文件ecosystem.json

pm2 startOrRestart /file/path/pm2.json : 經過配置文件啓動服務

以下是開發時pm2.json的內容

{
    /**
    * Application configuration section
    * http://pm2.keymetrics.io/docs/usage/application-declaration/
    * 多個服務，依次放到apps對應的數組裏
    */
    apps : [
    // First application
        {
          "name": "alumni2.0",
          "max_memory_restart": "300M",
          "cwd": "./",
          "script": "./app.js",
          "log_date_format": "YYYY-MM-DD HH:mm Z",
          "error_file": "./log/app-err.log",
          "out_file": "./log/app-out.log",
          "pid_file": "./log/node.pid",
          "instances": 6,
          "min_uptime": "60s",
          "max_restarts": 30,
          "watch": false
    }
    ]
 }
複製代碼

上述採用cluster模式啓動了6個服務進程；若是服務佔用的內存超過300M，會自動進行重啓。

配置項

name 應用進程名稱；
script 啓動腳本路徑；
cwd 應用啓動的路徑，關於script與cwd的區別舉例說明：在/home/polo/目錄下運行/data/release/node/
index.js，此處script爲/data/release/node/index.js，cwd爲/home/polo/；
args 傳遞給腳本的參數；
interpreter 指定的腳本解釋器；
interpreter_args 傳遞給解釋器的參數；
instances 應用啓動實例個數，僅在cluster模式有效，默認爲fork；
exec_mode 應用啓動模式，支持fork和cluster模式；
watch 監聽重啓，啓用狀況下，文件夾或子文件夾下變化應用自動重啓；
ignore_watch 忽略監聽的文件夾，支持正則表達式；
max_memory_restart 最大內存限制數，超出自動重啓；
env 環境變量，object類型，如{"NODE_ENV":"production", "ID": "42"}；
log_date_format 指定日誌日期格式，如YYYY-MM-DD HH:mm:ss；
error_file 記錄標準錯誤流，$HOME/.pm2/logs/XXXerr.log)，代碼錯誤可在此文件查找；
out_file 記錄標準輸出流，$HOME/.pm2/logs/XXXout.log)，如應用打印大量的標準輸出，會致使pm2日誌過大；
min_uptime 應用運行少於時間被認爲是異常啓動；
max_restarts 最大異常重啓次數，即小於min_uptime運行時間重啓次數；
autorestart 默認爲true, 發生異常的狀況下自動重啓；
cron_restart crontab時間格式重啓應用，目前只支持cluster模式；
force 默認false，若是true，能夠重複啓動一個腳本。pm2不建議這麼作；
restart_delay 異常重啓狀況下，延時重啓時間；
複製代碼

穩定運行建議

PM2是一款很是優秀的Node進程管理工具，它有着豐富的特性：可以充分利用多核CPU且可以負載均衡、可以幫助應用在崩潰後、指定時間(cluster model)和超出最大內存限制等狀況下實現自動重啓。

我的幾點見解保證常駐應用進程穩定運行：

一、定時重啓，應用進程運行時間久了或許總會產生一些意料以外的問題，定時能夠規避一些不可測的狀況；

二、最大內存限制，根據觀察設定合理內存限制，保證應用異常運行；

三、合理min_uptime，min_uptime是應用正常啓動的最小持續運行時長，超出此時間則被斷定爲異常啓動；

四、設定異常重啓延時restart_delay，對於異常狀況致使應用中止，設定異常重啓延遲可防止應用在不可測狀況下不斷重啓的致使重啓次數過多等問題；

五、設置異常重啓次數，若是應用不斷異常重啓，並超過必定的限制次數，說明此時的環境長時間處於不可控狀態，服務器異常。此時即可中止嘗試，發出錯誤警告通知等。

關於pm2的使用，主要仍是運用於常駐腳本。

參考資料：

pm2官網

pm2 github