La migliore configurazione sysctl.conf per carichi elevati - server di streaming di contenuti estremamente occupato

Qual è la migliore configurazione sysctl.conf per un server di streaming di contenuti ad alto carico ed estremamente occupato? Il server recupera il contenuto da server remoti come amazon, s3, ecc., Quindi utilizza php per trasmettere dinamicamente il contenuto all'utente senza salvarlo sul disco rigido. php usa CURL per recuperare il file, quindi usa flush () per trasmetterlo simultaneamente, quindi non c'è molto lavoro sul disco rigido ... solo rete e larghezza di banda.

Il server è quad core xeon, con scheda NIC full duplex da 1 Gbit, 8 gb di RAM e 500 GBx2 in RAID. L'utilizzo della memoria del server e il caricamento della CPU è piuttosto basso.

Stiamo eseguendo debian lenny e lighttpd2 (sì, lo so che non è ancora stato rilasciato :-)) con php 5.3.6 e php fastcgi con spawn-fcgi si legano su 4 socket unix diversi con 20 figli ciascuno. Il numero massimo di richieste fcgi è 20, con il modulo mod_balancer in configurazione lighttpd2 per bilanciare le richieste fastcgi tra questi 4 socket in configurazione SQF (prima la coda corta).

I nostri server utilizzano molta larghezza di banda, ovvero la connessione di rete è sempre occupata. Subito dopo 100-200 connessioni parallele, il server inizia a rallentare e alla fine non risponde, inizia a dare errori di timeout della connessione. Quando abbiamo avuto cpanel, non abbiamo mai avuto errori di timeout, quindi non può essere un problema di script. Deve essere un problema di configurazione di rete.

configurazione lighttpd2: processi di lavoro = 8, mantenere attive le richieste è 32, mantenere attivo il timeout di inattività è di 10 secondi e le connessioni massime sono 8192.

I nostri attuali contenuti sysctl.conf sono:

net.ipv4.tcp_fin_timeout = 1
net.ipv4.tcp_tw_recycle = 1

# Increase maximum amount of memory allocated to shm

kernel.shmmax = 1073741824

# This will increase the amount of memory available for socket input/output queues
net.ipv4.tcp_rmem = 4096 25165824 25165824
net.core.rmem_max = 25165824
net.core.rmem_default = 25165824
net.ipv4.tcp_wmem = 4096 65536 25165824
net.core.wmem_max = 25165824
net.core.wmem_default = 65536
net.core.optmem_max = 25165824

net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_orphans = 262144
net.ipv4.tcp_max_syn_backlog = 262144
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syn_retries = 2

# you shouldn't be using conntrack on a heavily loaded server anyway, but these are
# suitably high for our uses, insuring that if conntrack gets turned on, the box doesn't die
# net.ipv4.netfilter.ip_conntrack_max = 1048576
#  net.nf_conntrack_max = 1048576

# For Large File Hosting Servers
net.core.wmem_max = 1048576
net.ipv4.tcp_wmem = 4096 87380 524288

L'ottimizzazione delle prestazioni e l'identificazione di colli di bottiglia come questo sono un problema difficile da risolvere e spesso richiedono molte informazioni per la diagnosi. La chiave del processo è passare attraverso il processo che utilizza e vedere se riesci a trovare quale risorsa si sta esaurendo. Quando hai detto che il server non risponde per php, ma html serve ancora, questo è un punto dati interessante. Cosa c'è di diverso tra come vengono serviti? Potrebbe essere un sovraccarico del buffer di rete, oppure potrebbe essere più semplice. Potresti aver semplicemente esaurito il limite del processo figlio 20 fcgi figlio, e sono tutti occupati a servire i dati, mentre le nuove richieste vengono bloccate nella coda di ascolto (e il timeout alla fine) in attesa di un processo fcgi php.

Il vero trucco quando si tenta di ottenere visibilità sulla casella è accedere alla casella quando si verificano problemi e iniziare a raccogliere informazioni.

Per scoprire quanti processi php sono in esecuzione dovresti essere in grado di eseguire qualcosa del genere:

ps auxgmww | grep php

E se desideri contarli, anziché contarli tu stesso, puoi fare qualcosa del genere:

ps auxgmww | grep php | wc -l

Torna alla tua domanda originale sull'ottimizzazione delle prestazioni, prima di modificare syctl.conf potresti voler vedere cosa ti dice il tuo server quando si verifica il problema, puoi scoprirlo nel modo seguente:

sysctl -a > sysctl.txt

E quindi visualizza il tuo file di testo: sono molti dati, ma prima di mettere a punto un dato valore, vedi se l'output di sysctl riporta qualcosa su ciò che sta attualmente utilizzando per quel parametro sintonizzabile e su cosa potrebbe consumare. Un esempio sono i file aperti, che puoi vedere un esempio di output qui:

fs.file-nr = 3456   0   102295

Questo ci dice che stiamo usando 3456 descrittori di file, ma il nostro limite è 102295, quindi non siamo vicini al nostro limite. Se il primo numero fosse compreso nell'intervallo 100000, ciò ti direbbe che stai esaurendo i descrittori di file ed è quello che devi sintonizzare.