È normale che un processo pitchfork gestisca la maggior parte del carico: gli altri processi vengono selezionati solo quando il primo è occupato. È anche normale che la memoria cresca nel tempo. Sebbene dovrebbe raggiungere uno stato stazionario una volta che tutto, come le cache e ruby-JIT, è stato “scaldato”.
Ecco un grafico da uno dei nostri cluster di produzione, relativo a un periodo di 7 giorni. Questo traccia il singolo processo con il maggiore utilizzo di memoria. Le linee verdi tratteggiate indicano i deploy (cioè gli avvi freschi di pitchfork):
Quindi si può vedere che la memoria cresce dopo l’avvio iniziale, ma poi si stabilizza a poco meno di 1,4 GB. Questo cluster serve centinaia di siti, quindi forse non è il miglior paragone in termini di numeri… ma si spera che la visualizzazione della crescita sia utile.
Guardare i numeri RSS per processo non racconta la storia completa. Pitchfork è un “forking web server”. Quindi avvia il processo “mold” (modello) e poi tutti i worker vengono forkati da questo con uno schema di memoria copy-on-write. Quindi, anche se l’RSS potrebbe mostrare 500 MB per worker[0], circa 200 MB di quella quantità sono condivisi con il mold e tutti gli altri worker.
In un futuro non troppo lontano, speriamo di abilitare la funzione “reforking” di Pitchfork. Elimina periodicamente i worker e li riforca da un worker già scaldato, in modo che condividano la massima quantità di memoria possibile nel tempo. Tuttavia, è necessario un po’ di lavoro per assicurarsi che tutto il nostro codice sia compatibile con quel tipo di schema 