Generator PM2 config

Zarządzanie procesami Node.js

Bezpieczne (SSL)

Przetwarzanie Lokalne

100% Darmowe

Przejdź do narzędzia

Instrukcja

1

Wprowadź dane
Wpisz treść, wklej tekst lub załaduj plik z dysku.
2

Kliknij przycisk
Narzędzie natychmiast przetworzy Twoje dane w przeglądarce.
3

Pobierz wynik
Skopiuj gotowy tekst lub zapisz plik na urządzeniu.

                                                function runTool() {

                                                  return "Wynik gotowy w 0.1s";

                                                }

Proces PM2

Nazwa

Plik wejściowy

Instancje (max lub liczba)

Tryb

NODE_ENV

max_memory_restart

Watch (auto-restart przy zmianach)

Uzupełnij dane, aby wygenerować konfigurację PM2.

Oceń to narzędzie:

Powiązane narzędzia

Inne narzędzia, które mogą Ci się przydać

Generator konfiguracji PM2

PM2 to menedżer procesów dla Node.js. Uruchamia aplikację w tle, restartuje ją po awarii i pozwala skalować ją na wiele rdzeni procesora.

Najważniejsze opcje

Opcja	Znaczenie
instances	liczba instancji (max = wszystkie rdzenie)
exec_mode	cluster (wiele rdzeni) lub fork
watch	restart przy zmianie plików (tylko dev)
max_memory_restart	restart po przekroczeniu pamięci

Przykład

Konfiguracja z instances: 'max' i exec_mode: 'cluster' uruchomi aplikację na wszystkich rdzeniach i zrównoważy ruch między instancjami.

Podstawowe polecenia

pm2 start ecosystem.config.js — start
pm2 status — stan procesów
pm2 logs — podgląd logów
pm2 save + pm2 startup — autostart po restarcie serwera

Jak działa generator konfiguracji PM2

Generator zbiera wartości z formularza i składa z nich plik ecosystem.config.js, czyli zwykły moduł JavaScript, który eksportuje obiekt z tablicą apps. Każdy wpis w tej tablicy to jedna definicja procesu: nazwa, ścieżka do pliku startowego oraz parametry uruchomienia. Narzędzie nie porównuje danych z żadną wewnętrzną tablicą stałych — przepisuje dokładnie to, co wpiszesz, do składniowo poprawnego pliku, który PM2 potrafi wczytać.

Kluczowa jest relacja między polami instances i exec_mode. Wpisanie wartości 'max' powoduje, że PM2 w momencie startu odczytuje liczbę rdzeni dostępnych dla procesora i uruchamia dokładnie tyle instancji. Podanie konkretnej liczby daje stałą liczbę procesów niezależnie od maszyny docelowej. Tryb cluster ma sens dopiero przy więcej niż jednej instancji, bo tylko wtedy jest co równoważyć między rdzeniami; przy jednej instancji działa jak zwykłe uruchomienie pojedynczego procesu.

Pozostałe pola to proste przypisania. watch decyduje, czy PM2 obserwuje pliki i restartuje proces po każdej zmianie, max_memory_restart ustawia próg pamięci, po którym proces zostaje zrestartowany, a sekcja env wstrzykuje zmienne środowiskowe do uruchamianego procesu. Wartości z env nadpisują zmienne systemowe o tych samych nazwach, ale istnieją wyłącznie w pliku konfiguracyjnym — nie trafiają do repozytorium ani do systemu poza procesem, który je dostaje.

Przykład: konfiguracja dla serwera z 4 rdzeniami

Założenia: serwer ma 4 rdzenie i 2 GB pamięci RAM. Aplikacja to serwer HTTP w pliku server.js, a pojedyncze wystąpienie zużywa w szczycie około 300 MB.
W polu name wpisujesz api-prod, w polu script — server.js. Nazwa będzie widoczna w pm2 status, a ścieżka to plik, który PM2 ma uruchomić.
Ustawiasz exec_mode na cluster, a instances na 'max'. PM2 odczyta 4 rdzenie i uruchomi 4 instancje — po jednej na każdy rdzeń.
Wyłączasz watch, czyli ustawiasz false. Na produkcji obserwowanie plików powodowałoby restarty bez realnej potrzeby.
Ustawiasz max_memory_restart na 400M, czyli próg z zapasem wobec typowych 300 MB na instancję.
Dodajesz env z NODE_ENV=production i PORT=3000, zapisujesz plik i uruchamiasz pm2 start ecosystem.config.js. Wynik: 4 instancje działające równolegle, a górna granica pamięci całej aplikacji to 4 × 400 MB = 1600 MB, czyli 1,6 GB z dostępnych 2 GB.

Pola formularza i odpowiadające im wpisy w pliku

Pole w generatorze	Wpis w ecosystem.config.js	Efekt w PM2
name	name: 'api-prod'	nazwa procesu widoczna w pm2 status i pm2 logs
script	script: 'server.js'	plik startowy wskazywany przez PM2
instances: max	instances: 'max'	liczba instancji równa liczbie rdzeni, ustalana przy starcie
instances: liczba	instances: 4	stała liczba instancji, niezależna od maszyny
exec_mode: cluster	exec_mode: 'cluster'	równoważenie ruchu między instancjami na wielu rdzeniach
exec_mode: fork	exec_mode: 'fork'	pojedynczy proces, bez rozdzielania obciążenia
watch	watch: false	restart przy zmianie plików; sensowne tylko w developmencie
max_memory_restart	max_memory_restart: '400M'	restart procesu po przekroczeniu podanego progu pamięci
env	env: { NODE_ENV: 'production' }	zmienne środowiskowe dostępne w procesie

Praktyczne wskazówki użycia

Zacznij od fork, potem przełącz na cluster. Uruchom aplikację jako pojedynczy proces, sprawdź logi i zużycie pamięci, a dopiero potem zwiększaj instances. Błąd w kodzie przy 4 instancjach oznacza 4 razy więcej błędów w logach.
Sprawdź, czy aplikacja nadaje się do cluster. Tryb cluster zakłada wiele niezależnych procesów, więc stan trzymany w pamięci procesu, sesje w RAM albo zadania cykliczne odpalane w kodzie będą się dublować.
Ustawiaj max_memory_restart z zapasem. Jeśli próg będzie niższy niż realne zużycie aplikacji, PM2 zacznie restartować proces w pętli i zamiast stabilności dostaniesz ciągłe przerwy w działaniu.
Trzymaj nazwy opisowe. Rozróżniaj środowiska w polu name, np. api-prod i api-staging. Przy kilku aplikacjach na jednym serwerze pm2 status bez opisowych nazw staje się nieczytelny.
Po zmianie konfiguracji użyj pm2 reload. Przy trybie cluster reload wymienia instancje po kolei, więc aplikacja pozostaje dostępna, podczas gdy zwykły restart zatrzymuje wszystkie procesy na raz.

Ograniczenia generatora

Nie zna Twojej aplikacji. Nie sprawdzi, ile pamięci zużywa jedna instancja ani czy kod jest bezpieczny w trybie cluster. Wartości instances i max_memory_restart są przepisywane z formularza, bez weryfikacji z rzeczywistym profilem obciążenia.
Nie zna maszyny docelowej. Wpis 'max' rozstrzyga się dopiero przy starcie na serwerze produkcyjnym. Generator nie odczyta liczby rdzeni ani dostępnej pamięci środowiska, na którym plik zostanie uruchomiony.
Nie waliduje ścieżek ani zależności. Literówka w nazwie pliku script albo brak zainstalowanych paczek ujawni się dopiero przy pm2 start jako błąd uruchomienia procesu.
Nie zarządza sekretami. Wartości wpisane w sekcji env trafiają do pliku konfiguracyjnego w postaci jawnej. Hasła, tokeny i klucze API zostawiaj w pliku .env lub w zmiennych systemowych poza repozytorium.

Najczęstsze pytania

Cluster czy fork?

Cluster wykorzystuje wiele rdzeni i nadaje się do serwerów HTTP. Fork uruchamia pojedynczy proces — dobry dla zadań, które nie mogą działać równolegle.

Czy watch nadaje się na produkcję?

Nie. Watch zużywa zasoby i powoduje niepotrzebne restarty. Włączaj go tylko podczas developmentu.

Co z sekretami w env?

Trzymaj wrażliwe dane w pliku .env lub zmiennych systemowych, a nie w repozytorium z konfiguracją.

Jak wygląda plik ecosystem.config.js?

To moduł JavaScript, który eksportuje obiekt z tablicą apps. Każdy element tablicy opisuje jeden proces: name, script oraz parametry uruchomienia, takie jak instances, exec_mode, watch, max_memory_restart i env. PM2 wczytuje ten plik poleceniem pm2 start ecosystem.config.js.

Jak ustawić PM2, żeby używał wszystkich rdzeni?

Ustaw exec_mode na 'cluster' i instances na 'max'. PM2 odczyta liczbę rdzeni w momencie startu i uruchomi dokładnie tyle instancji, ile jest dostępnych. Przy jednym rdzeniu efekt będzie taki sam jak przy trybie fork.

Jak zmienić nazwę procesu w PM2?

Nazwa pochodzi z pola name w konfiguracji. Po zmianie wartości uruchom aplikację ponownie z pliku poleceniem pm2 start ecosystem.config.js albo usuń stary wpis i wystartuj proces od nowa, żeby w pm2 status pojawiła się nowa nazwa.

Co się dzieje po przekroczeniu max_memory_restart?

PM2 restartuje proces, który przekroczył ustawiony próg pamięci. Limit obowiązuje pojedynczą instancję, a nie całą aplikację, więc przy wielu instancjach łączny możliwy pobór pamięci to iloczyn liczby instancji i progu.

Czy można uruchomić kilka aplikacji z jednego pliku konfiguracyjnego?

Tak. Tablica apps może zawierać kilka definicji procesów, każda z własną nazwą, plikiem startowym i parametrami. Polecenie pm2 start ecosystem.config.js uruchomi wtedy wszystkie wpisy naraz.