MaxClients in apache. Come sapere le dimensioni del mio processo?

Da http://httpd.apache.org/docs/2.2/misc/perf-tuning.html

Il singolo più grande problema hardware che influisce sulle prestazioni del server web è la RAM. Un server web non dovrebbe mai essere scambiato, poiché lo scambio aumenta la latenza di ogni richiesta oltre un punto che gli utenti considerano "abbastanza veloce". Questo fa sì che gli utenti colpiscano l'arresto e ricaricano, aumentando ulteriormente il carico. Puoi e dovresti controllare l'impostazione di MaxClients in modo che il tuo server non generi così tanti figli da iniziare a scambiare. Questa procedura per farlo è semplice: determinare le dimensioni del processo Apache medio, guardando l'elenco dei processi tramite uno strumento come top, e dividerlo nella memoria totale disponibile, lasciando spazio per altri processi.

Il problema principale è che non riesco a capire come conoscere la dimensione, perché, beh, ho la dimensione di httpd su non più di 3888

Ma, se dobbiamo determinare il numero di MaxClients e ho 4 GB di RAM, quindi ottengo: 972, quindi dovrei usare come 900 nei MaxClients?

apache-2.2 httpd

— Larry
fonte

"Ho la dimensione di httpd su non più di 3888" - Penso di parlare per tutti quando dico "HUH?"

— womble

Risposte:

Innanzitutto, determina il PID di uno dei tuoi processi Apache.

Quindi puoi fare qualcosa del genere:

cat /proc/PIDHERE/status | grep VmRSS

Ciò produrrà le dimensioni (attuali) del set di residenti di quel particolare processo, simile a:

VmRSS: 304456 kB

Questo valore è come sembra, è la dimensione del processo residente nella RAM.

Quindi normalizza la tua unità di misura ( 4GB * 1024 * 1024 = 4,194,304 KB). Dividere:

4194304 KB / 304456 KB = 13.77 processes

Considera che probabilmente hai in esecuzione altri processi sul tuo sistema che consumeranno anche memoria, e idealmente vuoi minimizzare lo scambio, quindi probabilmente non vorrai 13 Apache MaxClients configurati (usando i miei numeri), vuoi un po 'meno (a tua discrezione ).

Questa è una stima approssimativa; la dimensione dei processi Apache può aumentare nel tempo a seconda del carico.

— loopforever
fonte

Sebbene l'RSS non includa pagine condivise, include anche le pagine contrassegnate come copy-on-write - ovvero c'è spazio su una macchina per più processi rispetto a (somma di rss) / (memoria fisica). Vedi anche la mia risposta altrove: lo spazio libero è essenziale per una buona prestazione.

— symcbean,

La previsione di maxClients dagli scenari di test è un punto di partenza, ma per risolvere correttamente il problema è necessario iniziare a misurare il comportamento dell'applicazione con il traffico reale.

Supponendo che Apache stia eseguendo il pre-fork ....

Imposta un cron job per contare il numero di processi httpd e l'output di "free". Nota che se il tuo server web fornisce contenuti da file locali (e in molti casi, anche quando non lo sono), la quantità di memoria disponibile per cache / buffer avrà un grande impatto sulle prestazioni. cioè se arrivate al punto di scambiare, le vostre prestazioni sul web sono probabilmente orribili!

Una volta che hai dei dati, tracciali su un grafico e fai una regressione di almeno due quadrati su di esso - estrapola per trovare il numero di client a cui raggiungi il limite di destinazione per l'utilizzo della memoria httpd. Un punto di partenza per il target di memoria sarebbe il minore tra l'80% della memoria fisica e l'80% della dimensione del contenuto.

(nota se MinSpareServers è impostato su un valore molto alto, i risultati potrebbero non essere precisi)

#!/bin/bash

LOGFILE='/var/log/httpd/memusage'
PIDS = `ps -ef | grep httpd | grep -v grep | wc -l`
MEM = `free | grep 'buffers/cache'`
DAY = `date '%Y-%m-%d %H:%M:%S'`
echo ${DAY} ${PIDS} ${MEM} >>LOGFILE

In un mondo ideale, dovresti anche misurare il tempo di risposta dell'URL nello stesso file di registro, ma sta diventando molto più complesso.

— symcbean
fonte

Per me, i buffer / cache cambiano molto poco sia che eseguano 11 client o quando il server ha raggiunto 86 o 151 client (e il server si è bloccato). Cosa ti aspetti di vedere nella tua variabile MEM? Ricevo due numeri, quindi mi chiedo se Ubuntu 12.04 stia dando qualcosa di diverso da quello che ti aspettavi.

— PeterB,

Prova a correre "gratis" e vedrai cosa mi aspetto (2 numeri). Se è vero che c'è una piccola variazione in questi numeri con diversi numeri di processi, allora stai eseguendo il server basato sugli eventi o l'impostazione di maxspareservers è sciocca. Se avessi pubblicato un campione dell'output e delle parti pertinenti del tuo httpd.conf, forse avremmo un'immagine migliore?

— symcbean,

.... e "crash"? Quale incidente?

— symcbean,

Siamo spiacenti, consultare pastebin.com/aHZCagVn per le impostazioni di httpd.conf e l'output di esempio. Per "crash" intendo troppi client, il server esaurisce la memoria e si blocca. Per ulteriori informazioni, consultare pastebin.com/fnXzBfQL .

— PeterB,

@PeterB sembra più probabile che MySQLd stia causando questo problema. Quando il killer OOM del kernel prende il via, uccide prima i peggiori trasgressori in base al valore di / proc / PID / oom_score_adj. Come evidenziato nel tuo output, mysqld è andato per primo. Potrebbe essere necessario regolare le impostazioni in my.cnf in modo più appropriato per adattarsi ai vincoli della VM. Come soluzione temporanea / temporanea, solo per vedere se riesci a evitare il kick killer OOM, prova ad aggiungere un file di scambio per memoria virtuale aggiuntiva; quindi sbarazzartene dopo aver identificato il tuo vero problema.

— loopforever