Nginx + php-fpm - Ogni php-fpm elabora il 70-100% di CPU durante l'esecuzione

Ho una situazione in cui si sta verificando quanto segue:

• Siamo su linode con 8 core, 8 GB di RAM, 2,6 ghz - usando nginx + php-fpm - stiamo ottenendo grafici estremamente alti di utilizzo della CPU (che non vogliamo essere un vicino VPS così cattivo) ...

• Abbiamo circa meno di 100 utenti alla volta sul sito - quindi questa situazione è anche incredibilmente imbarazzante - che il nostro utilizzo della CPU è molto elevato.

• Stiamo usando un framework php-saggio, discutibilmente orribile molto sconosciuto, forse cpu invece di altri framework ben noti, ben documentati e ben realizzati come wordpress o drupal in cui c'è MOLTA documentazione sulla cache (così come i plugin che gestiscono la memorizzazione nella cache) php su una piattaforma nginx + php_fpm.

• Quindi, abbiamo circa 6 processi php-fpm aperti che durante l'esecuzione, consumano individualmente GRANDI (30+, e spesso vicino al 99%) quantità di CPU - e non ho davvero la minima idea di come impedire loro di usare così tanto CPU . Non posso dire quali script php stanno causando questi picchi perché si verificano continuamente ... di solito solo 1 o 2 sono in esecuzione - ma quando tutti e 6 eseguono massimizziamo tutti gli 8 cpus.

• Il mio file pool.d / www.conf ha le seguenti impostazioni:

  pm = dynamic
  pm.max_children = 10
  pm.start_servers = 4
  pm.min_spare_servers = 2
  pm.max_spare_servers = 6
  

• Abbiamo fatto questo ^ setup perché, nel modo in cui lo sto interpretando, la nostra memoria è davvero incredibile (htop mostra 472/7000 + mb usati, nessuno scambio ecc.) E potremmo gestire molti più processi e spezzare la linea in attesa di ottenere elaborati - MA sfortunatamente, poiché ogni processo è troppo intenso sulla nostra CPU durante l'esecuzione - finiamo per guidare la nostra CPU attraverso il tetto - quindi non possiamo gestire abbastanza processi.

• La domanda : cosa possiamo fare per ridurre l'utilizzo del processo php-fpm cpu in modo da poter aumentare le impostazioni in quel file di configurazione del pool per php-fpm - e anche sì, il /var/log/php5-fpm.log ci sta urlando per aumentare i nostri figli e regolare / aumentare i nostri server min / max / start. Ma farlo fa impazzire il nostro carico come precedentemente indicato. Come possiamo farlo senza necessariamente utilizzare una cache o quali sono le nostre opzioni?

• La mia idea? Ho letto cose sull'uso di cpulimit per assicurarmi che nessun processo richieda più di una quantità assegnata di cpu - ma ciò rallenterà le cose per renderle inutilizzabili? O così facendo potremmo aumentare la nostra capacità di eseguire più di alcuni processi - ho anche pensato di gestire due pool - uno per il nostro sito Web rivolto in avanti (ciò che i clienti sperimentano) e un altro per un backend (che sta influenzando il nostro sito rivolto in avanti quando il tempo -consuming report in corso).

• Ho trascorso alcuni giorni a cercare, cercare su Google, ecc. Su questo argomento - ed è difficile perché la situazione di tutti è così unica per il loro sistema - il problema è trovarsi in un quadro così inaudito, forse scarsamente scritto - sta facendo è difficile trovare una soluzione. Non possiamo ancora eliminare questo framework: devo trovare una soluzione di qualche tipo.

AGGIORNAMENTO: ho implementato memcache per archiviare sessioni php - perché il framework si basa fortemente sulle sessioni utente e la natura del nostro sistema è che i dipendenti usano spesso più schede alla volta - ognuna delle quali torna alle sessioni per confermare abilità / dati utente / ecc. ... quindi spero di vedere un aumento delle prestazioni da questo - benvenuti a commentare questo, se lo desideri - vedrò come andrà domani quando supereremo le nostre ore di punta di volume più alto.

Un paio di cose da considerare (scusate in anticipo se le avete già considerate): prima di tutto, assicuratevi di ottimizzare la vostra configurazione nginx e invocare php-fpm solo quando assolutamente necessario. L'ultima cosa che vuoi fare è lasciare che php gestisca cose come pagine HTML statiche (cosa che farà felicemente).

In secondo luogo, dal momento che stai usando php-fpm, suggerisco di essere più aggressivo con il tempo di vita dei figli di php-fpm. Devi trovare il punto debole tra fili / bambini di breve durata e stabilità. I valori predefiniti di php-fpm sono troppo generosi per qualsiasi sistema di produzione, IMHO. Più un lavoratore è autorizzato a soddisfare le richieste, più instabile diventerà. Esiste anche un rischio maggiore di perdite di memoria e se questo framework a cui fai riferimento presenta bug come loop infiniti, che potrebbero causare problemi con il carico della CPU, ciò non dovrebbe danneggiare.

Ridurrei il numero pm.max_requestsper i tuoi pool di produzione. Penso che il valore predefinito sia 200. Vorrei iniziare da 50 e vedere dove ti porta.

In caso contrario, puoi anche provare queste opzioni globali (AFAIK sono tutte disabilitate per impostazione predefinita):

emergency_restart_threshold 3
emergency_restart_interval 1m
process_control_timeout 5s

Cosa significa questo? Se 3 processi figlio PHP-FPM escono con SIGSEGV o SIGBUS (ovvero arresto anomalo) entro 1 minuto, PHP-FPM dovrebbe riavviarsi automaticamente. Il processo figlio attende 5 secondi per una reazione sui segnali del master.

Ecco una bella panoramica di tutte le opzioni di configurazione che ho citato qui, così come altre: http://myjeeva.com/php-fpm-configuration-101.html

Spero che questi suggerimenti ti possano aiutare! Ricorda di modificare e osservare, sfortunatamente non sembra esserci una regola empirica per tutto ciò, come hai osservato, ci sono troppe variabili che influenzano il comportamento e la stabilità di PHP.

Infine, la funzione di limitazione della CPU di cui hai chiesto informazioni è documentata qui , ma ricorrerei solo se esaurisci ogni altra opzione. Se scegli questo percorso, farei sicuramente attenzione alle possibili interazioni tra le modifiche di PHP-FPM e la tua configurazione limits.conf. A quel punto etckeeper potrebbe essere un vero toccasana ! :)

In bocca al lupo!

Rouben

Stai eseguendo la cache del codice operativo, giusto?

Era l'APC che era il punto di partenza qui, ma è stato un pezzo difettoso per un po 'di tempo, ed è stato sostituito da Zend Opcache , che ora fa parte di PHP dal 5.5 e ha un backport in PECL per 5.3 e 5.4.