Newsgroup: it.comp.os.linux.sys
Titolo: Load pauroso server web

Ho un server web che gestisce un totale di domini ed
ogni tanto, nelle ore di picco, porta la macchina ad un
load di 30 o 40.
I siti sono praticamente tutti dinamici, il database è su
un server esterno. Lo stesso server gestisce dovecot e exim,
ma dubito siano loro il problema.
Apache è configurato cosi':
    StartServers          50
    MinSpareServers        5
    MaxSpareServers       10
    ServerLimit          150
    MaxClients           150
    MaxRequestsPerChild   20
Nulla di folle, credo.
Niente keepalive (ha un effetto massacrante sulle prestazioni,
se lo attivo mi collassa il server, è matematico)
12GB di ram, Xeon QuadCore 2.50
Un brutale "ps aux | grep -c http" mostra grosso-modo una media
di 50-60 processi, fino a 100-110 nei picchi, ma solo per pochi
secondi.
Questo è un vmstat:
# vmstat 1 10
procs -----------memory---------- ---swap-- -----io---- --system-- 
-----cpu------
  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy 
id wa st
30  1  82824 494404 861916 8243668    0    0   416   637    1    0 39 16 
34 11  0
21  0  82824 428584 861936 8243648    0    0    32   256 3633 2286 71 29 
  0  0  0
29  0  82824 440156 861944 8243876    0    0     4   508 3281 2862 68 32 
  0  0  0
14  0  82824 492716 861964 8243856    0    0     0  3104 2878 1992 72 28 
  0  0  0
  4  1  82824 604328 861980 8244332    0    0   460    44 3824 3196 71 
26  3  1  0
12  0  82824 748676 861984 8244328    0    0   192     0 3644 3525 66 23 
11  1  0
10  0  82824 681132 862004 8244736    0    0    20  3708 3120 3561 61 22 
15  1  0
11  0  82824 736108 862016 8244724    0    0   216     0 3332 5380 46 19 
34  0  0
  6  0  82824 617736 862040 8245064    0    0   112   280 3161 4788 63 
18 19  0  0
  1  0  82824 729580 862048 8237288    0    0     0  2052 3758 6278 36 
22 43  0  0
Cosa si potrebbe controllare? Non mi pare di vedere molti processi in
waiting, quindi i dischi non dovrebbero essere il problema. E nemmeno
il database che è esterno.
Eppure, i siti ospitati tardano a caricare, anche alcuni secondi di attesa.
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito è di fare il possibile per la
salvezza degli anni nei quali viviamo,
sradicando il male dai campi che conosciamo.

Gandalf Corvotempesta ha scritto:

Il collo di bottiglia.
hai scritto che il D.B. è esterno c'e qualche collo di bottiglia lungo 
il cammino?
D.B. esterno accertamento password mica interno, perchè se così fosse 
hai creato un traffico inutile e ingolfante.Chiama DB accerta password 
rispondi restituisci dati del DB, forse non sono chiaro ma . . . . . .

 rispondi restituisci dati del DB, forse non sono chiaro ma . . . . . .
Non ho capito niente, a dire il vero...


 load di 30 o 40.
abilita il mod server-status vedi cosa impianta la macchina?
ci gira del php? installa APC

 ci gira del php? installa APC
Si, sono praticamente tutti siti in PHP

 Si, sono praticamente tutti siti in PHP
io se non avessi APC installato avrei bisogno di altri 4 server almeno :p
dopo di che, a dispetto di quel che ti diranno qui, prova a mettere lighttpd 
come transparent proxy verso il tuo apache, vedrai che miglioramento 
notevole.

 chiamato
ho verificato, è globale.

 notevole.
te però sei al corrente che, al dispetto di quanto diranno qui,
proporre
di cambiare una intera infrastruttura non è *mai* una soluzione vero?
Comunque ho installato APC, vediamo che succede.
Dovrebbe far tutto da solo già con la configurazione base.

 processi, fino a 100-110 nei picchi, ma solo per pochi secondi.
Se il server "muore" quando ha 100-110 processi, dovresti abbassare il 
MaxClients e il ServerLimit a 90-100, in modo che apache metta in coda 
chi arriva dopo, invece di lanciare processi che il server non puo` 
gestire, rallentando tutti gli altri.
Visto che hai installato APC, controlla il carico che tiene ora, ed 
eventualmente regola quei valori in base al carico sopportato.
Il load comunque non e` un parametro affidabilissimo, soprattutto se hai 
il DB in rete. Puo` essere che quei 30-40 processi in coda (questo e` il 
significato del load) siano semplicemente in attesa su una syscall che 
contatta il DB, e che quindi sia il DB server lento, e non il webserver.
Controlla con top se il processore (tutti i core, premi 1 su top per 
vederli) e` veramente carico, o se tutti i processi sono in W(ait), e 
contemporaneamente controlla anche il carico del DB server.
Bye.

 Dovrebbe far tutto da solo già con la configurazione base.
fammi sapere!

 in ascolto sul proxy (stessa macchina eh!)
Mi stai quindi dicendo di aggiungere un ulteriore demone ad una
macchina
che fa fatica a tenere attivi quelli attuali?
Un po come gettare alcool per spegnere un incendio.

 contemporaneamente controlla anche il carico del DB server.
Be, come nel post precedente, non ho quasi niente in wait.
ho postato l'output di vmstat e da li si vede che in wait c'è
veramente poca roba,
per questo non capisco come mai il server collassa.

 Un po come gettare alcool per spegnere un incendio.
o accompagnare a casa un ubriaco con l'amico sobrio.
comunque, atteggiamento spocchioso, arrangiati

 comunque, atteggiamento spocchioso, arrangiati
Sinceramente, non mi pare un atteggiamento spocchioso.
Sto chiedendo aiuto perchè una macchina non sta in piedi
con il load attuale, tu mi dici di installare addirittura un secondo
server web (o proxy che sia, cambierebbe poco).
se prima a gestire 200 richieste con un singolo software non
riuscivo, dopo dovrò gestire le stesse 200 richieste ma con
due software, le cose possono solo peggiorare, visto che non
posso installare proxy o cache esterne al server.

 Sinceramente, non mi pare un atteggiamento spocchioso.
Al tuo posto farei la prova: giusto per dimostrare che non serve a
nulla ^_^ Tanto non ci vuole molto a fare una prova del genere.
As far as I know i reverse proxy non hanno cache, quindi non vedo come
potrebbe migliorare la situazione.
Ne ho provati diversi: nginx, apache, pound e sun web server.
Chiaramente servono ad altro, e non per migliorare le prestazioni di
una singola macchina, e per di più facendo girare sulla stessa il web
server e il reverse proxy ^_^
Lì, secondo me, ti devi passare il tempo a debuggare, anche guardando
le tabelle del DB (su usi pure un DB).
-- 
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
  printf $i }'; echo

 le tabelle del DB (su usi pure un DB).
Impossibile, troppi siti e sopratutto, non miei.

 Impossibile, troppi siti e sopratutto, non miei.
Allora basta. Non so se gestisci i problemi tramite ticketing. Chiudi il 
problema è scrivi: troppi siti e soprattutto, non miei.
Come pretendi di risolvere un problema, se non puoi nemmeno analizzarlo?
Eventualmente, se il sito non è tuo, tu non correggerai il problema. Ma 
spetta a te fare una analisi. E per fare una analisi, dio mio, non puoi 
fare nemmeno una select sul DB perché "i siti non sono tuoi"?
p.s.: io ho trovato un CMS drupal che creava una cache che ingigantiva 
giorno dopo giorno. Si trattava di pre-produzione, e non di produzione. 
Ma era una minchiata di facilissima soluzione. Ho segnalato il problema 
agli sviluppatori e via.


 fare nemmeno una select sul DB perché "i siti non sono tuoi"?
Non è *IL* sito, sono oltre 1800 i siti su quella macchina ed il
server database
ha, dati alla mano, esattamente 89482 tabelle. Di cui buona parte di
quelle
realmente usate stanno tutte in ram. (ovviamente anche i siti non sono
tutti utilizzati e non tutti fanno uso di php)
Devo analizzarli tutti uno per uno? Sarebbe impossibile per chiunque.
Considerato che su altri server analoghi dal punto di vista hardware
ho un numero almeno doppio di siti senza alcun problema o
rallentamento
(e più o meno la stessa quantità di traffico generata) volevo sapere
se in qualche modo potesse centrare la configurazione di apache.
Non ho processi in waiting, quindi presumo non sia un problema di
database esterno e/o di I/O su disco.
Non ho (sembrerebbe) problemi di ram, ci sono 12GB e non swappa
nemmeno più di tanto.
Che diavolo può essere?
Se il problema fosse lato siti, avrei altre soluzioni (come lo
spostamento
di massa di buona parte dei siti ospitati), ma prima di intraprendere
questa
strada non proprio semplice, mi sarebbe piaciuto fare un check lato
server
per scongiurare eventuali mie impostazioni errate.

 [...]
Ciao  Manlio


viene da dirti: confronta le configurazioni di Apache. Però sono cose 
buttate lì, quasi a casaccio.


 un milione di connessioni.
Si, anche il traffico globale è simile. Si parla di pochi megabit/s
E per pochi intendo < 8mbit nei picchi.

 posso installare proxy o cache esterne al server.
è esattamente l'opposto, lighttpd è bravo a gestire migliaia di connessioni 
simultanee, apache meno (per semplificare)
se le richieste le gestisce lighttpd la latenza dell'utente se la smazza 
lui, a quel punto non si creano tanti pid lato apache perché la 
comunicazione lighttpd -> apache è immediata.

 comunicazione lighttpd -> apache è immediata.
In che senso è immediata?
Se a lighttpd arrivano 200 richieste, lui dovrà inoltrare 200
richieste
ad apache.

Gandalf Mithrandir wrote:

vedila così, la latenza da utente remoto a apache è uno dei motivi per cui 
un server si impianta, finché l'utente non ha ricevuto l'ultimo bit il 
processo su apache è attivo.
se un utente ha una connessione balenga e per scaricare 100k ci mette 50 
secondi apache rimane connesso 50 secondi (e così riempe di processi il 
server poiché 1 processo = 1 pid), questo è overhead pauroso dato che lui ha 
già computato la risorsa ed è impegnato per un compito relativamente banale 
-> sparare fuori i bit richiesti.
se invece questo lavoro lo fa lighttpd (che è molto bravo nel farlo) e 
apache si interfaccia solo con lighttpd ogni richiesta tra apache e lighttpd 
è "immediata"  (al netto del tempo di computazione della risorsa ovviamente)
per questo che prima ti dicevo che avrai pure due demoni installati, ma cosa 
è meglio?
400 pid e servizi intasati con un demone
50 lighttpd e 50 apache pid e server funzionante con due demoni?
lighttpd configurato senza moduli è una scheggia e pesa pochissimo 
(lightweight appunto).
se ti serve ti mando un lighttpd.conf
-- 
give it away

 miglioramento notevole.
Non serve a nulla.
Stiamo parlando di 100 connessioni, non 1000 o 10k.

CtRiX wrote:

non mi avevi plonkato tu?
-- 
give it away

 ore di picco, porta la macchina ad un load di 30 o 40.
30 o 40 non è mostruoso.
E' normale avere 30/40 processi che chiedono priorità sull'I/O.
APC te l'hanno consigliato ma non è una soluzione definitiva.
Tu puoi avere 2 problemi:
1) il DB non è indicizzato e hai qualche sito (anche solo uno) che ci 
mette troppo a rispondere alle query e le altre richieste si accavallano.
2) la banda non ti basta. Il traffico è alto e per gestire tutte quelle 
richieste il tempo di ogni singola chiamata sale e le altre ti si 
accodano.

 non mi avevi plonkato tu?
Non avevi promesso di spararne di meno grosse, tu ?

 MaxRequestsPerChild   20
Puoi anche a provare ad alzare il MAxRequestPerChild (che è moooolto baso, i 
l.default è 10000) per avere meno processi che nascono/muiono di Apache, 
visto che non sembra un problema di memoria fisica piena.
-- 
Vide

CtRiX wrote:

e chi te l'ha detto se mi hai plonkato :p

 -> sparare fuori i bit richiesti.
se per scaricare 100k ci metti 50 secondi, di certo non è un problema
della
latenza. Neanche scaricando da satellite avresti 100k in 50ms.
(o meglio, non è un problema della sola latenza)
Se così fosse, sarebbe impossibile comunicare con chiunque fuori dal
continente
avendo latenze di 150ms su ADSL tradizionali.
Per non parlare delle connessioni GPRS.

 accodano.
Escluso, il server fa poco traffico e non occupo nemmeno la metà della
banda
disponibile.

 visto che non sembra un problema di memoria fisica piena.
Proviamo...
In serata metterò 200.

 banda disponibile.
E allora non è che usi quelle chiaviche di suphp o roba simile ??

 Per non parlare delle connessioni GPRS.
ok, non latenza in senso stretto, diciamo velocità di connessione.
comunque non capisco perché è così difficile da capire.
se un utente ha una connessione balenga e per scaricare 100k ci mette 50 
secondi apache rimane connesso 50 secondi, apache si riempe, load sale e tu 
ti trovi disperato.
mi pare veramente basico come ragionamento.
puoi incollare qui il result di server-status?
se fai in modo server-status assomigli a una cosa tipo:
WWWWC...W__W_.__.W.._WW__.__WWW..W.W.W__W.WW._._R.._..WW..WW..WW
..WWW...W._._.......WWW.........................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
........................
e non
_RKCKWKKRWK_KWKCKKRCCCKCKWKKR_CKK__CKCKWKCWRWCWWRK__RKCRCWKWRWKK
RCRWKKKCRWCKKKWKRWRCCWKRKKKCWRCWRKKWRRKKRKRCRK_CWWCRWRCC_RKWRRKC
KWKCKRKKKWKRKCCKWRKCKKKWRKKWCRRKCKWCWCKKWCWCCKCKWCKKCKKWCKKCKWCK
RC_RCKWKWCKKWKW_WRKKKRWKKRWKRKW_WKWRCCKK_WKWKKKCKKKCKWCKWWKKW_WK
WWKKKKCKKKWRKKKK___WWRWK_KRCKWKRKR_WKCK_KKC_CKWK_WRK_RWKKWCKKCCC
CCCCKKRKCKWCCKRKWWWRKCCCWCWCWKCKKRRKKKRKWKKWCRWKKWCWWCWRCKKKKKCC
WK_WW_KKW_KWKCW_W__W_RKR_KKRKKWKWKCRK_RC__KCRWKK_KKK_CKKRWW__KRK
KKCKCKRKKKWWCWWRRWKKKCWWC_KWKW__KCKWWKWK_KWWKKCCCKWRKCWCK_K__RWK
RK_K__KCWKRCK_K_RKKRW_CK_RKKKWCWK_KKWRCWKCRRWCKWCRKCWCRWCKWWCKCC
K__KKRK_KRKWKKCWCC_K_CCKKCKRRCCW_KWKKCCKCKR_W_WKRWKKWRCRK_WKCKWW
CWCR_RK____KCKW__CWKKKKKKKKR_WR_KRWRKKCKC_C_WKK__CRKC_CKWCK_CCKW
KC_KKKKR_CRKKRK_W_WWK_K_KKCC__RRC_WWR_CWWCWKKCCCCCCKWKWWWRKKR_CW
................................................................
................................................................
................................................................
................................................................
sei a posto

 E allora non è che usi quelle chiaviche di suphp o roba simile ??
In questo server no, php è compilato come modulo.
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito è di fare il possibile per la
salvezza degli anni nei quali viviamo,
sradicando il male dai campi che conosciamo.

 puoi incollare qui il result di server-status?
Più scarico di così:
   Current Time: Monday, 19-Apr-2010 15:00:44 CEST 
 
 
 
 
 
    Restart Time: Monday, 19-Apr-2010 12:25:03 CEST 
 
 
 
 
 
    Parent Server Generation: 23 
 
 
 
 
 
    Server uptime: 2 hours 35 minutes 41 seconds 
 
 
 
 
 
    Total accesses: 446768 - Total Traffic: 3.9 GB 
 
 
 
 
 
    CPU Usage: u8.1 s1.03 cu0 cs0 - .0977% CPU load 
 
 
 
 
 
    47.8 requests/sec - 438.7 kB/second - 9.2 kB/request 
 
 
 
 
 
    29 requests currently being processed, 26 idle workers 
 
 
 
 
 
  WWWCCC_WWW_CWWC__C_W_C__CWWC_W_W____WW__W_C_C________WS......... 
 
 
  ..W............................................................. 
 
 
  ...................... 
 
 
 
Però il sistema non è propriamente scarico:
top - 15:03:34 up 49 days,  2:26,  1 user,  load average: 16.11, 14.95, 
13.21
Tasks: 401 total,   1 running, 395 sleeping,   0 stopped,   5 zombie
Cpu0  : 45.7%us, 29.8%sy,  0.0%ni, 20.9%id,  1.3%wa,  0.3%hi,  2.0%si, 
0.0%st
Cpu1  : 40.0%us, 21.3%sy,  0.0%ni, 34.7%id,  3.7%wa,  0.0%hi,  0.3%si, 
0.0%st
Cpu2  : 43.4%us, 20.5%sy,  0.0%ni, 35.4%id,  0.3%wa,  0.0%hi,  0.3%si, 
0.0%st
Cpu3  : 36.6%us, 24.4%sy,  0.0%ni, 38.6%id,  0.0%wa,  0.0%hi,  0.3%si, 
0.0%st
Mem:  12298668k total, 11160600k used,  1138068k free,   817480k buffers
Swap: 16383992k total,    82824k used, 16301168k free,  8406652k cached


 47.8 requests/sec - 438.7 kB/second - 9.2 kB/request 
mi sa che il problema non è in apache, come dice davide bisogna capire 
quegli zombie che cavolo fanno.
tra le prime righe della lista delle pagine servite, ci sono pagine che non 
si aggiornano mai?
se hai quel fenomeno sono i file php generalmente che creano casino.
dopo quanti secondi hai impostato il max time esecution dei file php?

 connessioni ti mandano il l.a. a 16 c'e' qualche cosa che non va'.
E' esattamente per questo motivo che ho scritto sul gruppo.
Anche secondo me c'è qualche cosa che non va, a livello di apache
però, non tanto a livello di server. Dubito che un server QuadCore 2.50
possa andare ko con 47 connessioni.


 possa andare ko con 47 connessioni.
sempre da server-status riesci a capire quali sono i file che richiedono 
tanto calcolo/tempo per ogni esecuzione?

 dopo quanti secondi hai impostato il max time esecution dei file php?
120


 120
il mio è impostato a 30 secondi e lo trovo già grande abbastanza.
e quanta ram può consumare uno script php?
quanti moduli hai abilitato?
bisogna togliere tutti i moduli non necessari

 e quanta ram può consumare uno script php?
32M


 In serata metterò 200.
Prova, comunque se sono così poche connessioni non dovrebbe essere. Il disco 
è sano? Voglio dire, non risultano errori nel log del kernel no?
-- 
Vide

 è sano? Voglio dire, non risultano errori nel log del kernel no?
Nessun errore 'strano' nei log, è la prima cosa che ho verificato.


 In questo server no, php è compilato come modulo.
Dai una occhiata anche ai log di mysql.
Quando una tabella si danneggia, talvolta tutto continua a funzionare ma 
ad una velocità ridicola.

 Nessun errore 'strano' nei log, è la prima cosa che ho verificato.
Comunque se il load è alto *è* qualcosa che sta aspettando I/O, non ci sono 
cazzi. 
-- 
Vide

 ad una velocità ridicola.
Già fatto, nulla di strano.
anche i vari tools tipo mysqltuner non dicono nulla
di anomalo. Neanche troppe slow queries, stranamente.
Potrei provare a fare un optimize table...


 load di 30 o 40.
hai risolto?
-- 
give it away

 hai risolto?
No, manco per il cappero.
Ho portato a 2000 le connessioni e son stato
costretto ad alzare a 300 il MaxClient altrimenti,
oltre ai rallentamenti, mi ritrovo anche con
le persone che non sono in grado di accedere
al sito.
Durante il picco, avevo un 20% in waiting.
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito č di fare il possibile per la


 hai risolto?
Aggiungo: ho installato cband, per cercare di
tagliare le gambe a quei 2-3 siti che mi atterrano
il server, ma sembra che non funzioni a dovere.
Lo scoreboard viene creato, dalla pagina di status
vedo che alcuni virtualhost superano i limiti (e vengono
colorati di rosso) ma le connessioni sono comunque possibili.
Ad esempio, ho impostato 2mbit come banda, 20 rps e 10 connessioni,
però riesco ugualmente ad accedere al virtualhost sia superando i
20rps, sia superando le 10 connessioni.
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito è di fare il possibile per la


 No, manco per il cappero.
nell'ambito del voodoo:
non è che per caso c'è un firewall in cui si riempe la state table
e per ciò mette tutto in coda?
-- 
give it away

 e per ciò mette tutto in coda?
Non ho mai controllato, sinceramente.
Comunque, al momento:
# cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count
17951
# cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max
655360
e tutto funge.
Nel pomeriggio, quando il traffico sale, controllo meglio.
La cosa strana è che tra adesso e metà pomeriggio, ovvero quando
ci sono i picchi, il traffico è pressapoco lo stesso, le query
però triplicano. Da 5mbit di traffico tra il web ed il database,
arrivo a circa 15mbit.
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito è di fare il possibile per la


 Nel pomeriggio, quando il traffico sale, controllo meglio.
sì, controlla anche le altre macchine collegate al web server
-- 
give it away

 dovere.
Te l'ho già spiegato, ed anche il majale te l'ha detto: è peggio.
se quei due/tre siti hanno 100 connessioni simultanee che durano un 
secondo l'una, limitando la banda ne avrai sempre 100, ma dureranno di 
più.
Questo ovviamente occupa slot di apache in generale e non è bello, per 
tutta una serie di risvolti che a cascata possono riperquotersi anche sul 
DB.
Piuttosto, configura a modino  gzip/deflate.

 Da 5mbit di traffico tra il web ed il database, arrivo a circa 15mbit.
Non è necessariamente strano.
Magari un sito fa meno traffico ed un altro ne fa di più in quella fascia 
oraria. 
E quel sito che fa più traffico usa il database come io userei un 
martello pneumatico sul cranio del rompicazzo di turno su inna.
Ok, non vedi slow queries, ma se un sito per tirare fuori un dato ti 
esegue 50 query, pure se non sono slow, ci mette comunque tanto tempo...
Scopri quale sito è risolverai il problema.

 Piuttosto, configura a modino  gzip/deflate.
Che adesso è disattivato.
Già da stamattina stavo valutando di riattivarlo.
Fu disattivato a suo tempo per evitare di dover far comprimere ogni
volta
le pagine, già il server si caga nelle mutande sotto stress, se devo
farlo anche
comprimere sarebbe sparargli nei maroni.

 Scopri quale sito è risolverai il problema.
Fosse facile.
Con mytop non vedo mai infinità di query da parte dello stesso
utente.
Che dici, le delayed insert le attivo o le disattivo?
Se la tabella è trafficata, le delayed insert non vanno mai a buon
fine,
la connessione resta occupata e pian pianino mi collassa il database.
Ora son disattivate, per evitare di tenere appese decine di
connessioni
in attesa che la tabella si liberi, cosa che non capiterà mai, se è
molto
trafficata.

 trafficata.
Sono passato da tempo a postgres quindi non so che vantaggi possano 
fornire.
Sicuramente però le delayed inserts pososno dare problemi quando gli 
pseudo-programmatori ritengono che mysql sia un DB transazionale serio ed 
invece non lo è.
Io non rischierei.

 comprimere sarebbe sparargli nei maroni.
Comprimere non genera I/O.
Trasferire dati, si...

 Trasferire dati, si...
I/O no, ma load sulla CPU si.


 
sì, ma vai tranquillo che hai più overhead nello spedire 100k che nello 
spedire 5k gzippati.
non c'è motivo al mondo per mandare testo. una volta certi server avevano il 
coprocessore per gzippare i contuti, ora con tutti quei core che hai a 
disposizione vai super tranquillo
-- 
give it away

 disposizione vai super tranquillo
ah, dimenticavo, gzippa con livello di compressione di default, che va 
benissimo ed è leggero per la CPU.
ciao 
-- 
give it away

 benissimo ed è leggero per la CPU.
Più di 3 è praticamente dimostrato che è far spremere la CPU per nulla.
-- 
Vide

 disposizione vai super tranquillo
Ora son messo così:
top - 16:48:49 up 51 days,  4:11,  1 user,  load average: 41.11, 52.76, 
40.28
Tasks: 537 total,  51 running, 486 sleeping,   0 stopped,   0 zombie
Cpu0  : 55.3%us, 42.0%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.3%hi,  2.4%si, 
0.0%st
Cpu1  : 62.3%us, 37.3%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.3%si, 
0.0%st
Cpu2  : 71.7%us, 28.0%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.3%si, 
0.0%st
Cpu3  : 77.7%us, 22.0%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.3%si, 
0.0%st
Mem:  12298668k total, 10068608k used,  2230060k free,   951224k buffers
Swap: 16383992k total,    82824k used, 16301168k free,  6706472k cached


 Swap: 16383992k total,    82824k used, 16301168k free,  6706472k cached
e quali sono i primi processi che occupano CPU/Ram?
-- 
give it away

 e quali sono i primi processi che occupano CPU/Ram?
Apache scommetto.
La domanda è un'altra:
quali sono i Virtual hosts che hanno più richieste e quali sono queste 
richieste ?
Ad ogni buon conto, load a 40 o 50 non è necessariamente un problema.
Memoria ne hai ancora.
CPU libera non he hai. Mediamente 65% user ed il resto, 35% in System.
E' questo il problema.
O ci girano "sitoni" della madonna oppure sono scritti da cani.
for ( $i=1; $i<10000000; $i++ ) {
   # Aspettiamo un pò che fa freddo ed è bene che la CPU si scaldi
   # perchè è più efficente.
   # Magari qui faccio qualche query a capocchia così
   # anche il DB mi aiuta a scaldarmi.
}

 Apache scommetto.
dovrebbe capire quale pagina php(?) rallenta così tanto.
altrimenti continua a brancolare nel buio.
-- 
give it away

 O ci girano "sitoni" della madonna oppure sono scritti da cani.
Il problema è riuscire a capire quali siti mi stanno ammazzando
il server.
Oltre ad un top, che non mi torna utile in nessun modo, c'è qualche
tool che mi indichi quali vhost mi stanno ammazzando la CPU?
Non mi pare che l'output di server-status si possa ordinare per CPU...


 Non mi pare che l'output di server-status si possa ordinare per CPU...
no, ma openoffice è tuo amico.
prova a sortare per uso cpu / microsecondi per l'esecuzione.
cmq per esperienza le pagine problematiche stanno sempre tra le prime, e tra 
un refresh e l'altro le trovi lì a scaldare la cpu.
puoi anche provare con diff dopo aver salvato il risultato cosa è rimasto 
appeso.
insomma, ci vuole creatività
-- 
give it away

 Non mi pare che l'output di server-status si possa ordinare per CPU...
Vuoi anche la pappa pronta? :P
$ apache2ctl fullstatus|grep W|sort -n -k 5
poi prendi i PID dei processi che rompono le balle di più e con
$ strace -p $PID
dai un occhio alla roba che stan facendo.
-- 
Vide

 Che dici, le delayed insert le attivo o le disattivo?
Occhio che le delayed insert funzionano solo con MyISAM (e MyISAM in 
produzione è MALE)
-- 
Vide

 Non mi pare che l'output di server-status si possa ordinare per CPU...
Prova HSLAB HTTP monitor, per 30gg è free e può aiutarti a capire che
succede...
-- 
ValeRyo
XT600 "Katoki Pajama" - 
http://www.slimmit.com/go.asp?7Y9
GamerTag: 
http://card.mygamercard.net/IT/nxe/ValeRyo76.png
 

 insomma, ci vuole creatività
Più di così:
links 
http://localhost/server-status
 -dump | awk '{print 
$5,$12,$13,$14,$15,$16}' | grep GET | sort -nrk 1 | head
Una merda, ma almeno funziona.
I primi siti son sempre i soliti, ma nessuno, singolarmente,
supera lo 0.70 di CPU
Secondo me, è semplicemente troppo carico il server.


 produzione è MALE)
Non posso bloccarlo...


 dai un occhio alla roba che stan facendo.
Uhm, non avevo pensato minimamente a fare uno strace, però,
facendolo, vedo che sta fermo una mezzora:
# strace -p 25225
Process 25225 attached - interrupt to quit
wait4(26547,
^^^^^^^^^^^^^^^^^^^^^^^
il tempo passa inesorabile, o è un child di apache in attesa, ma
dubito, perchè con il tuo comando si filtrano solo i worker, oppure
non so che diamine stia facendo questo pid.
Prendendo altri pid, invece, vedo un output di questo tipo:
# strace -p 31733
Process 31733 attached - interrupt to quit
wait4(13006, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 13006
--- SIGCHLD (Child exited) @ 0 (0) ---
read(5, 0x7fff0a917417, 1)              = -1 EAGAIN (Resource 
temporarily unavailable)
getuid()                                = 0
close(5204)                             = 0
accept(3, {sa_family=AF_INET6, sin6_port=htons(2702), 
inet_pton(AF_INET6, "::ffff:xxx.xxx.xxx.xxx", &sin6_addr), 
sin6_flowinfo=0, sin6_scope_id=0}, [270582939676]) = 5204
fcntl(5204, F_GETFD)                    = 0
fcntl(5204, F_SETFD, FD_CLOEXEC)        = 0
clone(child_stack=0, 
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, 
child_tidptr=0x2b5485b7ece0) = 14094
wait4(14094, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 14094
--- SIGCHLD (Child exited) @ 0 (0) ---
read(5, 0x7fff0a917417, 1)              = -1 EAGAIN (Resource 
temporarily unavailable)
getuid()                                = 0
close(5204)                             = 0
Non mi convincono troppo i: "EAGAIN (Resource temporarily unavailable)".
Ne vedo uno ogni 2 secondi.
Toglietemi però una curiosità.
con lo status io vedo i processi di apache attualmetne in funzione.
Se per ciascun processo ho messo un limite di 2000 connessioni, ed ho
50 processi in funzione, è verosimile che ci siano almeno 2000*49
connessioni attive? Ne considero uno in meno (49 anzichè 50) perchè
il 50esimo processo potrebbe non essere 'saturo'.
E' valido come ragionamento o non centra un cappero?


 Secondo me, è semplicemente troppo carico il server.
Te l'ho scritto prima che hai la CPU a palla.
Se hai la CPU a palla, il carico sul server è troppo.
Se però sei a palla con 50 connessioni, come hai detto, allora il 
software è scritto con i piedi.

 Non mi pare che l'output di server-status si possa ordinare per CPU...
E' per questo che consiglio suexec + fastcgi:
- singoli user per singoli vhost (bene)
- php che gira con i privilegi di un utente specifico e non del webserver
- webserver che può essere threaded (col modulo, no) ed è bene
- prestazioni che tirando le somme sono equivalenti se non migliori
- possibilità di lavorare di fino sui singoli processi di un utente e non 
su tutto il webserver...
... E con TOP vedresti tutto quello che ti serve.
Max

 Se per ciascun processo ho messo un limite di 2000 connessioni
che io sappia 1 pid == 1 connessione, credo voglia dire che il pid muore 
dopo 2000 connessioni e viene rigenerato.
potrei dire una boiata però.
comunque, vedo che ti stai avvicinando, ci sei quasi a beccare il maiale :p
-- 
give it away

 connessioni attive? 
No. Una connessione alla volta per processo.

 ... E con TOP vedresti tutto quello che ti serve.
Ho ITK, vedo già quello che serve, ma non vedo nulla di "strano",
se non i 55 child occupati per un singolo vhost, come ho riportato.

 Perchè qualcosa dovrebbe accettare connessioni dall'esterno ?
Ma non è da me, è la porta remota:
# netstat -na | grep "2702"
tcp        0      0 ::ffff:aaa.aaa.aaa.aaa:
80       ::ffff:bbb.bbb.bbb.bbb:2702   TIME_WAIT
bbb = ip remoto, aaa = me
la 2702 remota si collega alla 80 mia.

 comunque, vedo che ti stai avvicinando, ci sei quasi a beccare il maiale :p
Si, ma mi sembra strano che un sito possa atterrare la macchina.
Mi sembra molto strano.

 sembra molto strano.
Facilissimo.
Posso fornirti codice PHP che atterra qualsiasi cosa lo faccia girare.
Passa all'access log e vedi che codice va a far girare.

 la 2702 remota si collega alla 80 mia.
quello allora è il trojan black diver che cerca di fare qualcosa.

 quello allora è il trojan black diver che cerca di fare qualcosa.
Sarà anche un trojan, ma non è da me.
Quella è la porta sorgente remota.

 Passa all'access log e vedi che codice va a far girare.
e' un joomla.

Gandalf Mithrandir wrote:

prova a disabilitare il VH e vedi un po' che fa il server..

 prova a disabilitare il VH e vedi un po' che fa il server..
Adesso è scarichissimo, al prossimo collasso sarà la prima
cosa che disattiverò.
In effetti quella storia della porta è strana, solitamente le
porte sorgenti sono altissime, >30-40.000, mentre questa
è misteriosamente bassa. Boh, resta sempre un problema
del client e non mio, afaik.
al massimo lo sego con iptables.

 al massimo lo sego con iptables.
sega sega. male non fa.
ciao

 sega sega. male non fa.
Ocio che poi il server diventa cieco :)
Ciao.
-- 
*** Linux user # 198661 ---_ ICQ 33500725 ***
    ***  Home  
http://www.kailed.net
  ***
        ***  Powered by openSUSE  ***

 prova a disabilitare il VH e vedi un po' che fa il server..
Non ho ancora disattivato il vhost, ma ho notato nei log che
e' pieno di
[Thu Apr 22 05:16:24 2010] [error] child died with signal 11
non vorrei che mi stia partendo la ram, per ricevere tutti
questi segfault.

 questi segfault.
Non ti preoccupare, io ho avuto per mesi errori di sto tipo dovuti 
principalmente a 
- bug di PHP
- porcate fatte con APC come key->value store
ovvero può essere tranquillamente software (anche se questo non esclude che 
potrebbe essere tranquillamente hardware)
-- 
Vide

Vide wrote:

anche io ne ho un po' di quelli sul mio server.

 O quello o stai usando un qualche modulo per apache che e' sifulo.
Tutto può essere.
Avevo attivato APC, per poi scoprire che non può funzionare se c'è
di mezzo anche Zend Optimizer e quest'ultimo non si può disattivare
a causa di alcuni script encodati.
Quindi ho staccato APC, anche perchè alcuni clienti mi han segnalato
dei fatal error randomici. googolando sembrerebbe sia proprio apc
che fa a cazzotti con Zend ed a volte spara fuori tali errori.
Considerato che è una cache, forse anche APC in conflitto potrebbe
generare dei segfault.
Comunque sia, uso ITK, ed anche lui potrebbe generare segfault.


 prova a disabilitare il VH e vedi un po' che fa il server..
Ok, load a 480.qualchecosa
Con lo script indicato da vide e leggermente modificato ho
segato i 3 vhost che superavano i 25 worker.
da 480 son passato a 8.34 di media.
C'� un modo per far schiantare un vhost se sta usando pi�
di X worker? Sarebbe interessante far sparare fuori un 5xx
agli utenti 'di troppo' in modo da dare un tetto massimo di
richieste.
Il problema sicuramente non � il numero di richieste, bens�
le letture su disco e database che tali richieste generano.
Se sparassi fuori un 5xx non avrei pressoch� alcun I/O su
disco ne tantomeno I/O su database.
Pensavo addirittura di killare i processi associati
ad un dato UID tramite crontab, ma � una soluzione penosa.
Un qualche modulo di apache?
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito � di fare il possibile per la


 Un qualche modulo di apache?
Non ho mai pensato a porcate del genere.
E' una cosa interessante da farsi quando vuoi perdere un cliente ...

 Un qualche modulo di apache?
non ne sono certo, ma darei un occhio a 
mod_throttle
mod_bandwidth
mod_limitipconn
mod_load
-- 
give it away