Trả lời nhanh: PM2 là trình quản lý tiến trình cho Node.js: chạy app dưới dạng dịch vụ nền, tự khởi động lại khi app crash, tự chạy lại khi VPS reboot (pm2 startup + pm2 save), gom log, đo RAM/CPU từng app, và cluster mode nhân app ra nhiều tiến trình tận dụng đủ nhân CPU. Bộ tứ lệnh sống còn: pm2 start, pm2 logs, pm2 restart, pm2 save.
Chạy node app.js trong SSH rồi tắt terminal, app chết theo. Chạy bằng nohup, app sống nhưng crash lúc 3 giờ sáng thì nằm đó đến khi bạn phát hiện. PM2 sinh ra để đóng vai người trực: app ngã thì đỡ dậy, máy khởi động lại thì gọi app dậy theo. Bài này đủ để bạn dùng PM2 tự tin trong công việc thật, kể cả mấy cái bẫy mà ai cũng dẫm một lần.
- PM2 = người trực app: crash tự dậy, reboot tự chạy, log gom một mối
- Combo bắt buộc sau khi start: pm2 save + pm2 startup, thiếu là reboot xong trắng tay
- Cluster mode nhân tiến trình theo số nhân CPU, chỉ hợp app stateless
- Ecosystem file thay cho chuỗi lệnh dài: khai app + env một chỗ, tái tạo máy mới trong một nốt nhạc
Vào việc trong 2 phút
sudo npm i -g pm2
cd ~/app
pm2 start npm --name shop -- start # app framework (Next.js, Nest...)
# hoac: pm2 start server.js --name api # file don
pm2 statusApp giờ chạy nền, SSH thoát thoải mái. Hai lệnh bắt buộc làm ngay sau đó:
pm2 save # luu danh sach app hien tai
pm2 startup # in ra mot lenh sudo, chay dung lenh doThiếu cặp này, VPS reboot (cập nhật, sự cố điện) là mọi app im lặng không dậy, lỗi kinh điển số một của người mới dùng PM2.
Bộ lệnh dùng hằng ngày
pm2 logs shop: xem log trực tiếp (--lines 200xem lùi); log là nơi ở của mọi câu trả lời.pm2 restart shop/pm2 reload shop: restart thường vs reload lần lượt từng tiến trình (cluster mode) để không rớt request nào.pm2 monit: màn hình RAM/CPU sống từng app; nghi ngờ leak RAM thì mở cái này trước.pm2 stop/pm2 delete: dừng tạm vs gỡ hẳn khỏi danh sách (nhớ pm2 save sau khi delete).pm2 env 0: soi biến môi trường tiến trình đang thấy, cứu tinh của lỗi "env đúng mà app bảo sai".
Cluster mode: vắt hết CPU, nhưng đọc điều kiện trước
pm2 start server.js --name api -i max # -i max = so tien trinh theo so nhanNode đơn luồng, một tiến trình chỉ ăn một nhân. Cluster mode nhân app thành N tiến trình chia nhau request, trên VPS 6 nhân là thông lượng tăng gần 6 lần với app CPU-bound. Điều kiện: app phải stateless, session/cache dùng chung phải nằm ngoài (Redis, database), vì request có thể rơi vào tiến trình bất kỳ. App có state trong RAM (đếm, cache object nội bộ) chạy cluster sẽ ra kết quả ma, kiểm tra trước khi bật.
Ecosystem file: cấu hình thành code
// ecosystem.config.js
module.exports = { apps: [
{ name: "shop", cwd: "/home/ban/shop", script: "npm", args: "start",
env: { NODE_ENV: "production", PORT: 3000 } },
{ name: "api", cwd: "/home/ban/api", script: "server.js", instances: "max",
exec_mode: "cluster", env: { NODE_ENV: "production", PORT: 4000 } },
]};pm2 start ecosystem.config.js dựng cả dàn app một lệnh. File này commit vào repo được, chuyển VPS mới hay dựng lại máy chỉ là clone + một lệnh, và là thứ Claude Code đọc hiểu để tự vận hành app cho bạn.
Ba bẫy còn lại hay gặp
- Log ăn đầy ổ: PM2 không tự xoay log. Cài một lần:
pm2 install pm2-logrotate: mặc định giữ log gọn gàng, khỏi có ngày 100% disk vì file log 30 GB. - max_memory_restart: app có tiếng leak RAM thì đặt
--max-memory-restart 500M: chạm ngưỡng tự restart, giải pháp tình thế đáng giá trong lúc tìm leak thật. - watch mode trên production:
--watchrestart theo thay đổi file, tiện lúc dev, tai họa lúc production (log ghi cũng tính là thay đổi nếu không ignore đúng). Production dùng restart chủ động qua deploy script.
Ba bẫy làm mất công nhiều nhất
- Quên cặp lệnh lưu danh sách và đăng ký chạy cùng máy. Chạy
pm2 startupin ra một lệnh, phải chạy đúng lệnh đó, rồipm2 save. Kiểm bằng cách khởi động lại máy chủ thật và xem ứng dụng có tự lên không. Nhiều người bỏ qua bước kiểm này và phát hiện ra sau lần bảo trì đầu tiên. - Biến môi trường không được nạp lại. Sửa tệp biến môi trường rồi
pm2 restartlà tiến trình vẫn giữ giá trị cũ. Phải dùngpm2 restart web --update-env. - Nhật ký phình to. Mặc định ghi mãi không giới hạn, vài tháng là đầy ổ. Cài mô đun xoay vòng nhật ký và đặt giới hạn ngay từ đầu.
pm2 install pm2-logrotate pm2 set pm2-logrotate:max_size 10M pm2 set pm2-logrotate:retain 7 pm2 set pm2-logrotate:compress true pm2 flush # xoa sach log hien tai khi can gap
Bộ lệnh chẩn đoán khi ứng dụng có vấn đề
pm2 status # trang thai, so lan khoi dong lai, thoi gian song pm2 logs web --lines 200 # xem log gan nhat cua mot app pm2 monit # bang theo doi truc tiep CPU va RAM pm2 describe web # xem toan bo cau hinh dang ap dung pm2 env 0 # xem bien moi truong that su cua tien trinh so 0 pm2 reset web # dat lai bo dem so lan khoi dong lai
Cột số lần khởi động lại trong pm2 status là chỉ báo sức khỏe quan trọng nhất. Con số tăng đều nghĩa là ứng dụng đang chết và được dựng lại liên tục, người dùng thấy lỗi ngắt quãng còn bạn tưởng mọi thứ bình thường vì trạng thái vẫn hiện đang chạy.
Chế độ cụm: khi nào dùng, khi nào đừng
| Loại ứng dụng | Dùng chế độ cụm được không | Lý do |
|---|---|---|
| Ứng dụng web không giữ trạng thái trong bộ nhớ | Được, nên dùng | Mỗi tiến trình xử lý một phần yêu cầu, tận dụng đủ số nhân |
| Ứng dụng lưu phiên đăng nhập trong bộ nhớ | Không, trừ khi chuyển phiên ra kho ngoài | Người dùng bị đăng xuất ngẫu nhiên khi rơi vào tiến trình khác |
| Ứng dụng có tác vụ định kỳ bên trong | Không | Mỗi tiến trình chạy tác vụ đó một lần, thành ra chạy nhiều lần |
| Ứng dụng giữ kết nối lâu dài | Được, nhưng cần cấu hình bám dính ở tầng proxy | Kết nối phải luôn về đúng tiến trình đã nhận |
Số tiến trình nên đặt bằng số nhân, hoặc số nhân trừ một nếu máy chủ còn chạy thứ khác. Mỗi tiến trình chiếm bộ nhớ riêng, nên máy 2 GB chạy bốn tiến trình thường hết bộ nhớ trước khi tận dụng được vi xử lý.
Khi nào nên bỏ trình quản lý tiến trình và dùng dịch vụ hệ thống
Trình quản lý tiến trình tiện, nhưng nó là một lớp nữa phải chạy và cũng có thể chết. Với máy chủ chỉ chạy một ứng dụng, đăng ký thẳng thành dịch vụ hệ thống gọn và bền hơn:
# /etc/systemd/system/web.service [Unit] Description=Ung dung web After=network.target [Service] Type=simple User=ban WorkingDirectory=/home/ban/app ExecStart=/usr/bin/npm start Restart=always RestartSec=5 Environment=NODE_ENV=production [Install] WantedBy=multi-user.target
sudo systemctl daemon-reload && sudo systemctl enable --now web journalctl -u web -f # xem log systemctl status web # trang thai
Chọn thế nào: nhiều ứng dụng trên một máy và cần bảng theo dõi thì dùng trình quản lý tiến trình. Một ứng dụng duy nhất và muốn ít lớp trung gian thì dùng dịch vụ hệ thống.
Câu hỏi thường gặp
PM2 với systemd khác gì nhau, dùng cái nào?
systemd là trình quản dịch vụ của hệ điều hành, mạnh và phổ quát nhưng cấu hình dài dòng với dân Node. PM2 chuyên cho Node: cluster, log, monit sẵn trong hộp. Thực tế PM2 startup chính là đăng ký PM2 vào systemd, hai tầng làm việc cùng nhau.
PM2 có chạy được app không phải Node không?
Được, Python, script bash... qua interpreter chỉ định. Nhưng đất diễn tốt nhất vẫn là Node; dịch vụ đa ngôn ngữ nghiêm túc thì Docker compose là khung phù hợp hơn.
Vì sao pm2 status báo online mà web không vào được?
Online = tiến trình sống, không nghĩa app khỏe. Soi tiếp: pm2 logs xem app in lỗi gì, app có nghe đúng PORT không, reverse proxy có trỏ đúng port đó không. Chuỗi nghi phạm: app → port → proxy → DNS.
Restart app có làm rớt người dùng đang online không?
Restart thường: có vài giây gián đoạn. Cluster mode + pm2 reload: các tiến trình thay nhau khởi động lại, request luôn có người tiếp, zero-downtime đúng nghĩa cho deploy giờ cao điểm.
