Apache raggiunge MaxClients e blocca il server


9

Al momento ho un server Apache2 in esecuzione con mpm-preforke mod_phpsu un VPS OpenVZ con 512 MB di RAM reale / 1024 MB (senza scambio). Dopo aver eseguito alcuni test, ho scoperto che la dimensione massima del processo che Apache ottiene è 23M, quindi ho impostato MaxClientssu 25 (23M x 25 = 575 MB, ok per me). Ho deciso di eseguire alcuni test di carico sul mio server e i risultati mi hanno lasciato perplesso.

Sto usando absul mio computer desktop richiedendo la pagina principale da un blog wordpress.

Quando corro abcon 24 connessioni simultanee, tutto sembra a posto. Certo, la CPU si alza, la RAM libera si riduce e il risultato è un tempo di risposta di circa 2-3 secondi per richiesta.

Ma se corro abcon 25 connessioni simultanee (il mio limite del server), Apache si blocca dopo un paio di secondi. Inizia l'elaborazione delle richieste, quindi smette di rispondere, la CPU torna al 100% inattiva e scade ab. Il registro di Apache dice che ha raggiunto MaxClients.

Quando ciò accade, Apache si mantiene bloccato con 25 processi in esecuzione (sono tutti in "W" se controllo lo stato del server) e solo dopo l' TimeOutimpostazione i processi iniziano a morire e il server inizia a rispondere di nuovo (nel mio caso è impostato a 45).

La mia domanda: è questo comportamento previsto? Perché Apache muore appena raggiunge MaxClients? Se funziona con 24 connessioni, non dovrebbe funzionare con 25, impiegando forse più tempo per rispondere a ogni richiesta e fare la fila per il resto?

Mi sembra un po 'strano che qualsiasi bambino che corre abpossa uccidere da solo un server web semplicemente impostando le connessioni simultanee ai server MaxClients.

Risposte:


17

HA! Finalmente ho trovato il problema da solo. È più correlato alla programmazione dell'amministratore del server, ma ho deciso di inserire la risposta qui perché, cercando su Google, ho scoperto che non sono l'unico con quel tipo di problema (e poiché Apache si blocca, la prima ipotesi è che c'è un problema con il server).

Il problema non è con Apache, ma con il mio Wordpress. Più specificamente con il mio tema. Sto usando un tema chiamato Lightworld e supporta l'aggiunta di un'immagine all'intestazione del blog. Per consentire ciò, controlla la dimensione dell'immagine usando la funzione di PHP getimagesize(). Poiché questa funzione stava aprendo un'altra connessione http al server per ottenere l'immagine, ogni richiesta da abstava creando un'altra richiesta internamente da PHP. Dato che stavo usando tutti gli slot disponibili sul mio server, queste richieste PHP sono state inserite in coda, ma Apache non è mai riuscita a raggiungerle perché tutti i suoi processi erano bloccati con la richiesta originale in attesa di uno slot per completare la richiesta interna PHP.

Fondamentalmente, PHP stava mettendo il mio server in uno stato di deadlock e Apache avrebbe iniziato a funzionare normalmente solo dopo il timeout di queste connessioni in attesa della loro richiesta "figlio".

Dopo aver rimosso questa funzione dal mio tema, ora posso il abmio server con tutte le connessioni simultanee che desidero e Apache le accoda come previsto.


Grazie per averlo pubblicato qui, ho cercato di capire un problema con esattamente gli stessi sintomi da qualche giorno a questa parte - penso che anche noi abbiamo un cast di deadlock!
James Yale,

come lo hai determinato, sono principalmente interessato ai registri e agli strumenti utilizzati per determinare la richiesta di uscita secondaria.
Anirudh Goel,

2

Quello che sta succedendo qui è che hai 25 thread in grado di accettare connessioni e stai inviando 26 richieste simultanee. L'ultima richiesta si trova nella coda del socket in base alla dimensione del backlog.

Il secondo problema è che qualunque cosa tu stia eseguendo che impiega 2-3 secondi, impiega abbastanza tempo per rispondere che le 25 connessioni simultanee lo stanno rallentando. sleep (1) potrebbe funzionare, ma, qualcosa in cui stai eseguendo il blocco dei file o il blocco della tabella da mysql, ogni richiesta parallela potrebbe essere in attesa prima del completamento fino a quando non raggiungono il timeout di 45 secondi.

23mb suona piccolo per un processo apache con mod_php e tutti i moduli caricati, quindi sospetto che potresti vedere quei processi apache prendere un po 'più di RAM mentre l'applicazione è in esecuzione. Non puoi davvero fare matematica con MaxClients e memoria del genere ... sarà un po 'vicino, ma non lo sai mai.

www-data  1495  0.1  0.9  56288 19996 ?        S    15:48   0:01 /usr/sbin/apache2 -k start
www-data  1500  0.0  0.5  49684 12436 ?        D    15:48   0:00 /usr/sbin/apache2 -k start

C'è una macchina, 56M e 49M processi.

un'altra macchina:

www-data  7767  0.1  0.1 213732 14840 ?        S    14:55   0:08 /usr/sbin/apache2 -k start
www-data  8020  0.2  0.1 212424 13660 ?        S    14:57   0:08 /usr/sbin/apache2 -k start

un'altra macchina:

www-data 28509  0.8  0.1 161720 10068 ?        S    14:39   0:43 /usr/sbin/apache2 -k start
www-data 28511  0.8  0.1 161932 10344 ?        S    14:39   0:43 /usr/sbin/apache2 -k start

Quindi, l'uso della memoria dipende molto dall'attività, quali moduli vengono caricati ecc. Negli ultimi due, credo che abbiamo disabilitato pdo & pdo_mysql poiché l'applicazione non li utilizza.

La vera domanda è: cosa stai facendo che richiede 3 secondi? Nel mondo di oggi, questa è un'eternità e considerata un'applicazione "bloccante". Apache normalmente non morirà, ma lascerà quei thread nella coda degli arretrati fino a quando non sarà in grado di servirli o il timeout delle richieste di attesa. Credo che la tua applicazione stia probabilmente causando il timeout di apache. Provalo su una pagina contenente solo phpinfo (); e vedere se i risultati sono gli stessi.


Grazie per tutti i consigli! Sono consapevole che devo ancora ottimizzare molte cose (ho appena iniziato a configurare il server un paio di giorni fa ed è la mia prima esperienza con un VPS), ma il problema era più profondo di così ... Ho pubblicato una risposta al domanda che spiega qual è stato il problema nel mio caso specifico.
Rodrigo Sieiro,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.