Devo costantemente ricaricare PHP-FPM

Abbiamo un server abbastanza pesante con nginx e PHP-FPM. Abbiamo 6 siti Web su questo server, con PHP-FPM e nginx. Il software è tutto vBulletin 3.8 e WordPress. I database si trovano su un server separato.

Ora, poiché questi sono siti Web molto popolari, normalmente abbiamo 7-8.000 visitatori online contemporaneamente, con ogni pagina che colpisce il database per la maggior parte. Credo che questa sia la causa dei nostri problemi.

Poiché disponiamo di così tanti database di grandi dimensioni sul server MySQL e, poiché le query potrebbero, onestamente, essere molto migliori nel software, penso che MySQL a volte non riesca a restituire i risultati a PHP in modo tempestivo, creando un effetto a cascata che alla fine fa sì che tutto si fermi fino a quando non ricarichiamo PHP-FPM. Dopo averlo fatto, le cose ricominciano a funzionare bene.

Il motivo per cui ho problemi a risolvere questo problema è perché non riesco davvero a discernere nulla dai registri. Nel registro delle query lente di MySQL non vedo nulla di interessante quando si verificano tempi di inattività. Nei registri nginx, vedo migliaia di voci che dicono che la richiesta di lettura è scaduta o che la connessione è scaduta (a PHP-FPM). E nei log di PHP-FPM, vedo molte righe che dicono "timeout dell'esecuzione (31 sec), terminando

Quindi a questo punto non so proprio dove cercare il problema. Ovviamente, qualsiasi cosa stia accadendo sta accadendo perché questi script non vengono eseguiti abbastanza rapidamente a volte (normalmente si caricano in meno di un secondo, ma succede qualcosa che fa salire il tempo di caricamento). Questo succede molte volte al giorno ed è diventato un bel problema per noi.

Per ora ho semplicemente un crontab per il servizio di php5-fpm ricaricato ogni 10 minuti, che si occupa del problema del crash. Naturalmente, quando PHP viene ricaricato, nginx genera un errore del gateway 502, quindi non è molto una soluzione.

PHP esegue la cache APC, se è importante. Ho letto in alcuni punti che APC può causare l'impiccagione in determinate circostanze.

Qualsiasi suggerimento sarebbe utile. Mi piacerebbe davvero non dovermi preoccupare di questa macchina per tutto il tempo.

Ulteriori informazioni possono essere fornite ovviamente. Fammi sapere di cosa hai bisogno.

Aggiornamento: ho appena copiato su apc.php in una radice web e vi ho effettuato l'accesso per vedere le nostre statistiche. Le cose sembravano buone. Quindi ho fatto clic sul collegamento per accedere a Statistiche utente e BOOM il server si è bloccato immediatamente. Ho ricaricato php-fpm e poi ricaricato la pagina delle statistiche dell'utente e tutto è andato bene. Atteso un minuto, ricaricato di nuovo, il server si è bloccato di nuovo.

Quindi questo sembra decisamente correlato ad APC. La domanda è: come possiamo risolverlo?

Config APC:

[apc]
apc.enabled="1"
apc.stat = "1"
apc.max_file_size = "2M"
apc.localcache = "1"
apc.localcache.size = "256"
apc.shm_segments = "1"
apc.ttl = "3600"
apc.user_ttl = "7200"
apc.gc_ttl = "3600"
apc.cache_by_default = "1"
apc.filters = ""
apc.write_lock = "1"
apc.num_files_hint= "10000"
apc.user_entries_hint="10000"
apc.shm_size = "1G"
apc.mmap_file_mask=/tmp/apc.XXXXXX
apc.include_once_override = "0"
apc.file_update_protection="2"
apc.canonicalize = "1"
apc.report_autofilter="0"
apc.stat_ctime="0"

Aggiornamento 2: abbiamo fatto alcuni progressi su questo qui. Si scopre che il plugin di memorizzazione nella cache di WordPress (W3 Total Cache) è ciò che ha causato gli arresti anomali. Non sappiamo ancora perché, ma con questo disabilitato, abbiamo eseguito PHP per quasi 4 ore senza ricariche, rallentamenti, crash. Stiamo ancora utilizzando APC nei forum vBulletin e non ci sono problemi. Esiste un modo per determinare PERCHÉ APC si sta arrestando in modo anomalo? Mi piacerebbe usarlo sulle nostre installazioni di WordPress, ma non a scapito di un sistema fragile.

Stai usando php-fpm, quindi 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 generosi per qualsiasi sistema di produzione, IMHO.

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

In caso contrario, potresti 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. I processi figlio attendono 5 secondi per una reazione sui segnali del master.

Questo dovrebbe mantenere il tuo pool di thread di lavoro PHP piacevoli, freschi e puliti. Più a lungo un lavoratore è autorizzato a fornire richieste, più instabile diventerà. C'è anche un rischio maggiore di perdite di memoria.

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 questo, ci sono troppe variabili che influenzano il comportamento e la stabilità di PHP.