Newsgroup: it.comp.os.linux.sys
Titolo: Parliamo del load

Se c'è una cosa che proprio non capisco è come
rilevare chi sta facendo schizzare il load di un server
alle stelle.
Poco fa un server è passato, nel giro di 10 minuti, da load
2.5 (normale per quel server) a load 60.
La macchina era ancora reattiva (non so come sia possibile ma
è così). Stando al "top" non ho nulla in io waiting, tant'è
che iowait era in valori prossimi a 1-2%, che son sempre nella
norma.
La ram era libera e niente swap.
Nulla di anomalo in "us" "sy" e "ni"
Nulla di anomalo nei processi, nessun processo impazzito che
magari occupava il 100% di cpu o petabyte di ram e nemmeno troppi
processi in esecuzione.
Cosa caspita devo controllare ancora? E sopratutto, come faccio
a sapere chi mi fa sbarellare la macchina e perchè? Vorrei
capire bene, in modo da risolvere e/o prevenire, prima che un
prossimo load bello alto mi faccia collassare il server.
(ultima domanda: è vero che il load dovrebbe essere sempre inferiore
al numero di cpu? ad esempio, 8 core e load inferiore a 8 o 10 per
essere 'normale')

 che non signfica che non possa essere superiore.
Assolutamente no.

 'normale')
No, assolutamente falso.
Di solito il load sale in maniera anomala per la ragione che la CPU e lo 
scheduler non riescono a stare dietro al numero di processi che richiede 
priorità e se ne creano altri che aggravano la situazione.
Ad esempio, sale quando hai un server apache che serve 100 client al 
secondo e hai problemi di rete tra il server ed il database.
Questo succede perchè apache non servirà 100 client al secondo ma magari 
ne servirà 50. I rimanenti 50 si aggiungeranno ai 100 del secondo 
successivo fino a quando scoppia tutto.
Idem per problemi di accesso al disco.
Conclusione: talvolta è normalissimo avere il load a 200.
Talvolta il load è un sintomo di qualche problema da indagare.
Se la tua CPU era scarica e la ram pure, a mio avviso devi:
1) controllare se ci sono parecchi processi (fork) dello stesso programma 
che magari si è impallato
o
2) controllare se un singolo programma ha generato un sacco di thread 
ognuno dei quali richiedeva priorità
p
3) verificare se avevi problemi di network o, peggio, di disco
In base a quanto sopra, 
- fare tuning dei programmi (apache, per esempio, le configurazioni degli 
workers)
- installare versioni non buggate dei programmi
- fixare problemi di hardware/rete eventuali
Per mia esperienza, il 90% delle volte è colpa del sistemista (che non ha 
fatto tuning) o dell'architettura che non scala.
Il restante 10% sono problemi hardware/rete.
Il tutto dipende da te.
Max

 che non signfica che non possa essere superiore.
Per processore in questo caso si intende anche il numero di core?
Ad esempio, se ho 8 core, e load a 4, perch� mai ci sono 4 processi
in attesa di essere seriviti? Ho dei core disponibili...
Oppure, pi� probabilmente, significa che avendo 8 core, ho gi� 8
processi che occupano i processorie e 4 di troppo che son li in attesa?
(avrei bisogno di 12 core, in questo caso, giusto?)
-- 
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.

 fatto tuning) o dell'architettura che non scala.
E' sicuramente uno scazzo mio.
Potrei provare a disattivare il keepalive che da quanto ho notato in
passato fa più danni di quelli che dovrebbe risolvere.
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito è di fare il possibile per la


 motivo apache si incarta in questo modo.
Nel 90% dei casi, qualche query minchiona verso SQL.
-- 
Paranoia is a disease unto itself. And may I add: the person standing
next to you may not be who they appear to be, so take precaution.
-----------------------------------------------------------------------------
http://bofhskull.wordpress.com/

 Nel 90% dei casi, qualche query minchiona verso SQL.
Mi salirebbe anche il load sul server mysql.
Inoltre ho uno script che sega le query che sono in
esecuzione da oltre 30 secondi e me le notifica via
mail, e non ho ricevuto alcuna notifica.


 Mi salirebbe anche il load sul server mysql.
Non necessariamente in maniera altrettanto avvertibile.
Quando dovesse ricapitarti, prova a vedere cosa c'è in esecuzione lato DB.
Se vedi query che stanno generando tabelle temporanee, sono
probabilmente la causa del problema.


 probabilmente la causa del problema.
Quasi sempre vengono generate tabelle temporanee, visto che buona
parte dei siti sono in wordpress.
Ma anche se fosse un problema di tabelle temporanee, per far schizzare
il load a 60 nel giro di pochi minuti, la creazione di tali tabelle
dovrà essere superiore ai 30 secondi come minimo.
Non ho mai visto creare una tabella temporanea, interrogarla e
distruggerla in meno di 30 secondi ed allo stesso tempo far schizzare
il load a 60 per 20 minuti (anche il load 15 era schizzato alle stelle)
L'unica casistica potrebbe essere un sovraffollamento verso un sito,
che ad ogni accesso crea tabelle temporanee. In tal caso, se la singola
query resta sotto i 30 secondi io non la vedrei a livello di
monitoraggio, ma avrei centinaia di query che farebbero schizzare il
load del web. Ma ho controllato, i siti non erano affollati (anche qui,
ho uno script che conteggia quanti processi fcgi ci sono per ciascun
utente, ne fa la somma, calcola la RAM e la CPU usata per ciascun utente
ed in caso me lo notifica oltre a mostrarlo a video nel caso lo 
richiamassi manualmente come ho fatto, ma in quel momento non avevo 
molto traffico)


 dovrà essere superiore ai 30 secondi come minimo.
Di nuovo, non necessariamente.
Fino a $tmp_table_size, mysql le crea in ram, dopodichè passa ad usare
il disco.
Se hai un $tmp_table_size troppo piccolo, quindi, e un determinato
dominio ha query che portano alla creazione di tabelle temporanee su
disco (in quanto maggiori di ecc. ecc.), quelle query vengono trattate
svariati ordini di grandezza più lentamente del normale, e il sistema
"si punta"...


 passato fa più danni di quelli che dovrebbe risolvere.
Ti parlo di 2 settimane fa:
apache (mpm worker, quindi threaded e non forked) + suexec + fastcgi + php 
(attaccato a mysql).
Ogni domenica il server crashava brutalmente (è un sito che di domenica 
riceve 4 volte il traffico di tutta la settimana).
E' bastato, semplicemente, modificare le impostazioni dell'MPM worker per 
risolvere il problema.
- usa mpm_worker e non il prefork
- raddoppia ThreadsPerChild
- raddoppia MaxClients
- dimezza MaxSpareThreads
- dai un valore a MaxRequestsPerChild (250 è ragionevole, invece di zero).
Il keepalive lo ho ad ON ma può valere la pena disattivarlo.

 "si punta"...
Non mi pare troppo piccolo:
tmp_table_size = 67108864
sono 64M o giù di li, giusto?


 Il keepalive lo ho ad ON ma può valere la pena disattivarlo.
Keepalive OFF, mi sembrava di averlo lasciato attivo ma non è così.


 Ma solo tu lo sai che cosa fai andare su quella macchina quindi...
apache e basta, il resto � ininfluente, c'� dovecot ed exim ma occupano
meno di zero come risorse.


 Ho avuto problemi a compilare il worker, appena ho modo riprovo.
No debian ?? ahi ahi ahi ahi...

 No debian ?? ahi ahi ahi ahi...
Si, debian, ma con un pannello il che si traduce in:
"doppio ahi doppio ahi doppio ahi doppio ahi" 

 tmp_table_size = 67108864
Dipende dai database che deve servire...
A me par *molto* piccino, ma vedi te...


 se non entrano in azione non dovrebbe schizzare il load alle stelle)
Se le richieste restano appese in attesa allora ricadi esattamente in uno 
di quegli esempi che facevo inizialmente.
 

 di quegli esempi che facevo inizialmente.
Porca zozza, ed io ho persino dimezzato i child spawnabili da fcgi.
Ora li raddoppio di nuovo.
Però, ho capito bene cosa intendi dire, ma se la richiesta non fa nulla,
ovvero non forka child, non carica php e non lo interpreta nemmeno, non
dovrebbe (in teoria) generare grossi problemi, non trovi?
Cosa può comportare avere una richiesta ad una pagina php che però
non fa assolutamente nulla, a livello di load? Resta appeso giusto
il child di apache, che è relativamente leggero, visto che non deve
nemmeno processare le pagine.


 
vi parlo per esperienza perche' sono stata colpita da questa situazione su
un mail server che utilizzava un block driver non proprio ottimale.
il load average e' in altre parole il numero di processi in stato RUN nel
singolo istante di tempo secondo lo scheduler. In ogni istante tu hai un
isieme di processi attivi nella macchina tra cui molti o moltissimi in WAIT
(per eventi esterni, es. timers, input da tastiera, input da rete) alcuni
in IOWAIT (cioe' bloccati in una syscall che richiede al kernel di fare IO
su devices es. dischi) e alcuni in RUN.
di tutti quelli in RUN, puoi averne un numero inferore o superiore al numero
di CPU che hai in macchina (che siano fisiche o multicore non importa)
Se il numero di processi in RUN (molto grezzamente il load-avg) e' minore o
uguale al numero di core, e' tutto a posto e il sistema e' ok. 
se il numero di processi in RUN e' superiore al numero di core, si ottiene
che, in media, lo scheduler non potra' piu' affidarsi per fare lo switch
dei processi alle sole syscalls o richieste di wait, ma dovra' forzatamente
interrompere processi attivi e funzionanti allo scadere dei relativi
timeslice (funzione di preemption) per dare il controllo agli altri in
attesa. Questo chiaramente abbassa le prestazioni percepite perche
letteralmente i processi devono contendersi le CPU ed il load-avg aumenta.
poi c'e' da vedere se utili i meccanismi di processor affinity oppure no, il
tipo di sistema a dischi che hai, ecc.
perche' potrebbe accadere, e accade, che magari hai dei dischi lenti e un
processore dual-core dove un core viene utilizzato tutto dal processo
interno del kernel per la gestione dei dischi in raid oppure speso in
iowait negli interrupt e quindi potresti avere una situazione nella quale
non hai processi attivi piu' di tanto ma il tempo e' speso a seguire i
dischi (magari perche' hai messo lo swap in mirror, stai usando swap e il
kernel perde tempo a mirrorare le pagine in/out dallo swap)
usa anche i comandi iostat e vmstat per capire cosa succede.
ho trovato anche utilie htop
ciao
 Andrea

 processare le pagine.
Se usi FastCGI hai *anche* il child del PHP oltre a quello di apache.
Per quanto se ne dica, un fork() è sempre peggio in termini di 
prestazioni di un thread ed è per questo che uso il worker.
Una cosa che, per mia esperienza, è il caso di tenere basso, è il numero 
di Min/MaxSpareServers (io ad esempio ho 5/15).
Impostarlo a 50 o 100 con il prefork può avere un senso se devi gestire 
picchi improvvisi ma con i thread ha poco senso.
Prova ad intervenire anche su quei parametri che sempre per esperienza 
mia, sono delle grandi PITA.
AAAH DIMENTICAVOOO!!!
spesso e volentieri i client si vanno a ricaricare i contenuti statici 
senza cachearseli.
Questo aiuta, non poco dire, a diminuire le richieste
    <IfModule mod_expires.c>
      ExpiresActive On
      ExpiresDefault "now plus 24 hours 3 minutes"
      ExpiresByType text/html "now plus 24 hours 3 minutes"
      ExpiresByType text/plain "now plus 24 hours 3 minutes"
      ExpiresByType text/xml "now plus 24 hours 3 minutes"
      ExpiresByType text/css "now plus 24 hours 3 minutes"
      ExpiresByType application/x-javascript "now plus 24 hours 3 minutes"
      ExpiresByType image/gif "now plus 24 hours 3 minutes"
      ExpiresByType image/jpg "now plus 24 hours 3 minutes"
      ExpiresByType image/png "now plus 24 hours 3 minutes"
      ExpiresByType image/x-icon "now plus 24 hours 3 minutes"
    </IfModule>
Se non devi ricompilarti il mondo aggiungilo come globale per tutto il 
server e poi riferisci in plancia l'esito!
Max

 server e poi riferisci in plancia l'esito!
Me lo segno, appena faccio manutenzione faccio il reload di apache.
AFAIK, queste modifiche non vengono rilette con un graceful.


 AFAIK, queste modifiche non vengono rilette con un graceful.
AFAIK si.
però una botta di at ti permette di riavviarlo anche stanotte 
(verificando che la configurazione sia giusta con un graceful) senza 
problemi di sonno.

 letteralmente i processi devono contendersi le CPU ed il load-avg aumenta.
Si, ok, ma la domanda �:
se il load indica 4, significa che ho QUATTRO processi in esecuzione
nello stesso secondo e che non possono essere 'accodati e sospesi'
dallo scheduler del kernel? Il che vale a dire che su 400 processi in 
esecuzione conteggiati da top, solo 4 stanno funzionando in quel preciso
istante, gli altri aspettano candidamente.
E' corretto questo?
Come faccio a vedere questi famosi 4 processi in esecuzione? Io ne ho
circa 400, se 4 sono in esecuzione, quali sono?
Ma comunque mi pare strano, se cos� fosse, non avrei valori decimali,
come faccio ad avere 4.5 processi? Quel mezzo processo che roba � ?


 problemi di sonno.
Sonno? What's sonno?


 picchi improvvisi ma con i thread ha poco senso.
Quanto traffico/siti hai su quel server?
Considera che io sono in prefork, non in worker.


 come faccio ad avere 4.5 processi? Quel mezzo processo che roba � ?
e' che non sempre ci sono 5 processi in coda RUN, alcune volte 4, alcune 5 per cui in
media 1 minuto diventa 4,5
attenzione che il load-avg non e' cosi' semplificato, ma ci vanno in mezzo anche altre 
considerazioni ma puoi usare questo ragionamento come base di partenza.
leggi anche: 
http://www.linuxjournal.com/article/9001

 leggi anche: 
http://www.linuxjournal.com/article/9001
Si, lo leggerò, ho anche un libro in casa sul kernel e lo scheduler
ma il problema è che sono argomenti fin troppo complessi per i miei
gusti, non ho mai approfondito perchè non ho mai capito bene come
funziona la gestione dei processi su Linux.

core? Mi pare strano.
E' press'a poco la definizione di core :-)
L'illusione che due processi (ciascuno dei quali dura un'ora), girino
"insieme" impiegando un'ora in tutto, e' dovuto al fatto che ciascuno
dei due viene suddiviso in fettine, ogni fettina costituita o di vera
computazione o di attesa di qualche cosa (che non richiede CPU), e le
fettine di computazione di uno vengono fatte corrispondere alle fette
dove l'altro e' in attesa.
Ma la CPU, in ogni momento, può dedicarsi a una fettina sola. L'unico
modo perché possa dedicarsi a due è avere in corpo due unità distinte
di esecuzione -- ma allora hai una CPU "dual core".
Leonardo
-- 
Enough, enough!  But, stranger, ere we part,
Glancing farewell to each nefarious bier,
This warning would I beg you take to heart:
There is an end to e'en the worst career!

 di esecuzione -- ma allora hai una CPU "dual core".
Adesso è tutto chiaro. :)
In un dato istante, un biprocessore quad potrà eseguire al massimo 8
processi in R, gli altri li mette obbligatoriamente in S.
Dico bene?
Quidi se il mio load-1 corrisponde ad 8, significa che la media degli
ultimi 60 secondi ha visto contemporaneamente 8 processi in R, ovvero
entrambe le CPU occupate al 100% perchè questi 8 processi, in un modo
o nell'altro, non potevano essere sospesi e quindi li doveva eseguire
insieme.

 insieme.
NO!!!!
Significa che negli ultimi 60 secondi, mediamente, ogni secondo c'erano 8 
processi che chiedevano di entrare in stato R.
Fin qui hai detto giusto ed il tuo ragionamento si DEVE fermare.
Il LOAD non è per nulla collegato al consumo della CPU.
Esistono load a 20 su monoprocessore monocore con CPU quasi scarica.
Se tu hai 100 processi che vogliono fare I/O da rete e sono in un ciclo 
select/poll di CPU non consumano praticamente nulla ma chiedono comunque 
al kernel la priorità di verificare se c'è qualcosa da leggere sul socket.

 prefork, non in worker.
VHosts ne ha pochi, due o tre, ma considera che gestisce un quotidiano 
nazionale quindi come visite non è bassissimo.
macchina KVM con 4 core assegnati.

 Fin qui hai detto giusto ed il tuo ragionamento si DEVE fermare.
Ok, ed in tal caso sarebbe tutto ok.
8 processi per 8 core.
Se avessi avuto 16, la media degli ultimi 60 secondi in ogni secondo
c'erano 16 processi che volevano entrare in R, e visto che io ho 8
core e non 16, qualche cosa non quadra.
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito è di fare il possibile per la


 e non 16, qualche cosa non quadra.
No.
Tu stai dicendo che un pentium 4 (quindi monoprocessore) non può gestire 
più di 1 client alla volta.

 più di 1 client alla volta.
Ed infatti sembrava strano anche a me.
Però in una altra risposta han detto che il numero di processi
eseguiti simultaneamente è praticamente la definizione di core.
Se il processore ha un solo core, esegue un solo processo in un
dato istante. Mi sembra strano, sinceramente. Però, da un certo punto
di vista, può essere vero. Lui esegue un solo processo in una data
frazione di tempo. Più è performante, meno tempo impiega ad eseguire
il processo, quindi a parità di tempo vengono eseguite più operazioni.
Esempio:
se per eseguire un processo un monocore da 1ghz impiega 10 secondi,
un monocore da 2ghz ne impiegherebbe 5, quindi nella stessa frazione
di tempo, 10 secondi, riesce ad eseguire 2 processi.


 quindi a parità di tempo vengono eseguite più operazioni.
Esatto: frazione.
Il load viene calcolato su diversi secondi, mentre lo scheduler switcha 
processi anche migliaia di volte al secondo. Quindi nessun processo viene 
eseguito in modo continuativo per diversi secondi, perche` viene sempre e 
comunque interrotto (ad esempio) ogni millesimo di secondo dal kernel 
stesso per lanciare lo scheduler e controllare "a chi tocca".
 
Come dice CtRiX, se in quei 10 secondi partono 10.000 processi, e ognuno 
entra subito in una select() e attende la risposta per 10 secondi (metti 
che c'e` un problema di rete), avrai un load di 10.000 anche su un 
monoprocessore, ma la CPU avra` carico quasi zero.
Bye.

 la definizione di core.
Ogni core, ovvero ogni processore, può dedicarsi ad un solo programma 
alla volta.
Se durante l'esecuzione il programma comunica al kernel che può 
"ignorarlo" per un secondo intero, impiegando 1ms per questa operazione 
di comunicazione,  tale processore potrà eseguire 1000 programmi (o thread 
o processi) in un secondo (pensa alle fettine o time slice di cui ti 
hanno parlato).
Avrai quel core al 100% di CPU usage ma avrai un load di 1000 (se hai un 
core solo).
Secondo me non sei ancora convinto.

 Secondo me non sei ancora convinto.
No, non lo sono, guarda qui:
# top -bn1 | head -n 10
top - 12:50:04 up  1:00,  1 user,  load average: 89.00, 76.58, 59.14
Tasks: 4334 total,   4 running, 4329 sleeping,   0 stopped,   1 zombie
Cpu(s): 11.7%us, 12.3%sy,  0.0%ni, 72.6%id,  2.4%wa,  0.1%hi,  0.9%si, 
0.0%st
Mem:   4128532k total,  4066964k used,    61568k free,   268088k buffers
Swap:  2629624k total,      692k used,  2628932k free,  1273412k cached
   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND 
 
 
  3255 vmail     20   0  179m  19m 1332 S   47  0.5   1:18.90 imap 
 
 
28993 root      20   0 22220 4444  840 R   20  0.1   0:00.22 top 
 
 
  2918 root      20   0  134m 6232 3724 S    4  0.2   0:19.01 
dsm_sa_datamgr3 
 
Un solo processo in "R"
# top -bn1 | grep " R "
28993 root      20   0 22220 4444  840 R   20  0.1   0:00.22 top


Tasks: 4334 total,   4 running, 4329 sleeping,   0 stopped,   1 zombie
Guarda pero' quanti di quei processi sono in stato D, e se si', quali
sono.



Non sono troppo d'accordo con questa regola.
Innanzitutto occorre definire meglio un processo o fettina o dir si voglia.
Solitamente si chiamano thread le informazioni che passano per un core 
di una cpu. Sono l'unità di esecuzione massima che un core puà svolgere 
in un ciclo di clock.
Parlando di linguaggio macchina, un programma è descritto da più 
istruzioni per la cpu. Vecchie cpu svolgevano le istruzioni in uno o più 
cicli di clock (ovvero ogni istruzione era divisa in uno o più thread). 
Attualemente anche i single core organizzano i thread cercando di 
soddisfare più parti di istruzione, ottimizzando i tempi morti dovuti ai 
caricamenti in memoria. Quindi ogni istruzione viene divisa in più 
parti. Un thread è composto da alcune parti.
Per quanto riguarda le cpu multicore, ovviamente possono gestire più 
thread in contemporea.
Anche se è una leggenda metropolitana che corre veloce in molte sale 
console italiane, con supporto di molti "vecchi del mestiere", non è 
vero che se ho due core posso fare girare due programmi in parallelo, 
non è vero che se ho due cpu ho due task che girano e le altre in 
attesa. Anzi, con word uso più core in contemporanea, per dare l'idea.
Dipende da molti fattori, per esempio l'OS. Se l'OS non lancia alla CPU 
istruzioni efficentabili, l'utilità delle CPU multiple collassa. Se uso 
un DOS 6 su di un dual core ottengo (grossomodo) la medesima efficenza 
di un single core su cpu a pari clock. Ed anche sul clock occorrerebbe 
aprire una digressione, visto che la veocità di clock rende 
proporzionalmente più veloci le cpu single core, ma per le multicore la 
proporzione salta.
CMQ, quello che interessa qui non è tanto l'efficenza dei thread, ma in 
che stati versa il sistema.
Intanto, solitamente la cpu non è il problema. I colli di botiglia sono 
la quantità di ram disponibile (ed il conseguente accesso alla memoria 
virtuale), l'eccessivo utilizzo dello stack di rete,  pool di 
comunicazione coi db eccessivamente usati, motori RDBMS vicini al 
collasso, ecc.
Purtroppo top, ps e consimili danno non permettono di avere una 
disgnostica immediata del sistema. Occorre studiare la situazione, 
partendo dalla tipologia di sw che è in uso.
Per esempio, usi un web server con piu siti che usano un db?
Quanti sono i task contemporanei verso il db?-----> occorre monitorarli 
usando le utility db!
Quante sono i task interni contemporanei al server http?
Quanti sono i task contemporanei relativi all'application server.
ecc.

 funziona la gestione dei processi su Linux.
infatti non e' necessario approfondire, altrimenti saresti Alan Cox. Devi
pero' imparare le basi di come funzionano le cose. 
ciao
 Andrea

 di esecuzione -- ma allora hai una CPU "dual core".
AMEN.
pero' non ho mai capito le cpu hyperthread. quelle magari soffrono di
personalita' multiple ??
Andrea

 sospesi e quindi li doveva eseguire insieme.
no. e' che si sono trovati per caso ad essere eseguiti nello stesso istante
ma su unita' di elaborazione diverse.
i processi *che non possono essere sospesi* e simili, fanno parte di una
tecnica di gestione chiamata "real time" che non e' il caso di trattare ora
se non hai ben interiorizzato la tecnica standard.
Andrea

 core e non 16, qualche cosa non quadra.
fammi la cortesia di imparare alcune parole e concetti:
un CORE: una unita' di esecuzione presente in macchina, che puo' eseguire
una sola cosa per volta ma con la tecnica del time-sharing puo' apparire
che faccia piu' cose insieme.
una CPU: un chip fisico che contiene uno o piu' core.
stato RUN: un processo pronto per essere eseguito su un core. un processo
puo' entrare nello stato RUN se non ci sono altri ostacoli od attese per la
sua prosecuzione. se un processo si mette in attesa di un pacchetto dati,
puo' essere che questo passi dallo stato RUN allo stato WAIT. Non
necessariamente un processo in stato RUN e' in quel momento in esecuzione
su un core.
Esecuzione: istante di tempo in cui un processo in stato RUN viene
effettivamente eseguito da un core.
ciao
 Andrea

 sono.
Nulla, nessun processo in D
C'è un solo processo in R che effettivamente legge dei dati da
disco e forse può causare un load da paura.
Ma un solo processo può far schizzare a valori prossimi al 100
un server quadcore solo per leggere dei dati?


 personalita' multiple ??
Da quel che ho capito io (correggetemi se sbaglio) hanno un core in piu`, 
ma non completo. In pratica eseguono due istruzioni contemporaneamente, 
ma, per esempio, solo se una e` in virgola mobile (quindi la fa fare alla 
FPU) e una in intero (e la fa fare alla ALU). In pratica solo se ha 
risorse hardware disponibili per eseguirle in parallelo.
Con il fatto che hanno pipeline lunghe e parallelismo interno, anche CPU 
con 4 ALU e 2 FPU potrebbero trovarsi con tutte le risorse occupate con 
una singola istruzione.
Bye.

 su un core.
C'è una incongruenza, credo.
Tu dici: "stato RUN: un processo pronto per essere eseguito su un core. 
un processo puo' entrare nello stato RUN se non ci sono altri ostacoli 
od attese per la sua prosecuzione"
Ok.
Poi dici: "se un processo si mette in attesa di un pacchetto dati,
puo' essere che questo passi dallo stato RUN allo stato WAIT"
non "può essere" ma "deve".
Altrimenti, se si mette in attesa di qualche cosa, ovvero qualche cosa
ne blocca la sua prosecuzione, non può essere in RUN andando contro
a quanto hai scritto subito prima.


 di tempo, 10 secondi, riesce ad eseguire 2 processi.
ni. tu parti dal fatto che un processo venga eseguito in un tempo fisso e
che non abbia mai tempi di attesa. un po' forzata come ipotesi ma sempre
possibile.
quello che succede e' che ogni core ha a disposizione tante fette discrete
di tempo in cui puo' essere ma puo' anche non essere che vi sia qualcosa da
fare.
nel caso che ci sia sempre qualcosa da fare lo scheduler (che a sua volta e'
un processo!!!) decidera' in base a propri criteri a quale processo dare il
core e a quali altri far saltare il turno.
se allarghi la frazione di tempo che esamini ti appare come dici tu, ma
perdi di dettaglio in una maniera cosi' evidente da scollegarti dalla
realta', anche perche in media un processo e' sempre molto piu' in attesa
che in esecuzione e quindi i momenti di inizio, fine e esecuzione non sono
immediatamente predicibili se non nei casi piu' semplici.
Andrea

 fare.
Si, era un esempio il mio.
E' più semplice parlare in secondi che in nanosecondi ed è più facile
parlare con numeri umanamente comprensibili che altro.
Da quel che ho capito, se io ho un solo core, il core eseguirà
al primo secondo, un secondo del processo1, al secondo secondo un
secondo del thread2 e così via.
Se ho due core, i due thread vengono eseguiti in parallelo, uno
per thread dimezzando di fatto il tempo di esecuzione e raddoppiando
quindi le performance.
(ovviamente semplificando)


 infatti e' cosi'.
No

 28993 root      20   0 22220 4444  840 R   20  0.1   0:00.22 top
siccome la coda e' estremamente dinamica e' abbstanza difficile trovade dei
processi in R che non siano il processo utilizzato per scovarli.
ci son volute tre o quattro prove per ottenere questo:
root@home:~# ps ax | grep R
13668 ?        Ss     0:00 kdeinit Running...
 8332 pts/1    R+     0:00 ps ax
 8333 pts/1    R+     0:00 grep R
quindi non puoi affidarti ad una sigola situazione. 
Andrea

 ecc.
tutto giusto, ma anche qui si esula da significato di load-avg di cui
stavamo discutendoon l'OP, discussione su cui eravamo giunti per fornire le
basi per poi proseguire le indagini nei modi che tu indichi.
Andrea

Alessandro Pellizzari wrote:

anch'io ricordo una cosa simile. mi pare che fossero necessarie
ottimizzazioni specifiche per poter usare in maniera decente questi
processori. 
diciamo che e' un core "finto" e che per la nostra discussione lo
assimiliamo ad un core vero, altrimenti non se ne esce piu'.
andrea

 a quanto hai scritto subito prima.
gia'. dopo n-mila messagi nel gruppo ogni tanto una parola sbagliata puo'
scappare.
:)
 Andrea

alef-0 wrote:

scusate mi rendo conto che mi si stanno intrecciando in concetti in testa.
alef-0 hai ragione tu, ho usato di nuovo una parola sbagliata, perche'
pensavo al core, mentre qui si parlava di una intera CPU che lavora
comunque in time-sharing quindi di clienti ne serve molti, tutti quelli che
puo'.
io stavo a basso livello, il messaggio e' a livello piu' alto e la mia
risposta non e' quindi applicabile.
Andrea

 basi per poi proseguire le indagini nei modi che tu indichi.
Precisamente.
A me non interessa risolvere il problema subito (l'ho già risolto,
ho riavviato apache), interessa sapere il perchè si verifica ciò
in modo da saperlo risolvere in autonomo nel caso si ripresentasse
anche su altre macchine.
In poche parole, non vorrei la pappa pronta (che non porta mai a
niente di utile), vorrei piuttosto che qualcuno mi spiegasse come
cucinare la pasta, per intenderci. Poi se manca il sale o se la
pasta è ancora cruda lo saprò valutare da me :)


 (ovviamente semplificando)
Molto semplificando, come alef-0 ci ricorda, ma e' cosi'. bisogna solo
essere coscienti che stiamo utilizzando delle semplificazioni sostanzione.
Andrea

 un server quadcore solo per leggere dei dati?
potrebbe, se usi un sottosistema del kernel che magari non e' multithread e
quindi ti ritrovi core-bound quindi non riesci ad occupare gli altri core e
il processo rimane in attesa.
mi pare pero' strano perche su disco ti dovrebbe aumentare la
percentuale %SYS e %IOWAIT.
da indagare con vmstat e iostat
Andrea

 scappare.
A ok, quindi confermi?
Un processo in RUN č obbligatoriamente in esecuzione,
ovvero sta calcolando? Se fosse in attesa di input o altro
non potrebbe essere in RUN ?
Ma non quadrerebbe comunque. E' stato detto che il load
viene impattato dai processi in run, che potrebbero attendere
un input da disco o da rete. In tal caso il load aumenta ma la
cpu resta scarica.
Ma se cosě fosse, stando a quanto dici, un processo in RUN
non potrebbe essere in attesa di nulla, ergo non concorrerebbe
al calcolo del load.
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito č di fare il possibile per la


 al calcolo del load.
processo in RUN non e' in attesa di eventi esterni e proprio per questo
concorre al calcolo. i processi in qualche tipo di wait invece non
concorrono.
Amdrea


Premetto che spesso capire capire cosa blocca il sistema è l cosa più 
difficile che può capitare al sistemista.
Non vorrei essere troppo semplicistico, dici che la copla è di apache e 
che sostanzialemnte i sisti usano wordpress.
Come reagisce apache all'uso di una singola pagine di un singolo sito. 
Apre un task specifico? Non è che i task rimangano attivi costantemente 
per colpa di un banale errore di qualche applicativo? Che ti dice dmesg? 
(o consimili, non ci hai detto che os usi). Non è che rimangono  n-mila 
transazioni verso il db costantemente attive?

 comunque un accodamento all'interno del kernel.
Ok.
Supponiamo load = 10 e macchina ad 8 core.
Significa che nella media degli ultimi 60 secondi, ho avuto richiesta
di esecuzione contemporanea di 10 programmi, in un dato secondo.
In pratica tutti e 10 chiedevano priorità alla CPU.
Se questi 10 programmi possono essere accodati, il load resta a 10 ma
non si dovrebbero notare rallentamenti perchè lo scheduler li accoda.
Se i 10 programmi non possono essere ignorati e vogliono tutti priorità, 
avrò load comunque a 10 e macchina completamente collassata perchè ci
son 2 processi di troppo a voler essere eseguiti nello stesso istante
e tutti gli 8 core sono completamente occupati.
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito è di fare il possibile per la


 transazioni verso il db costantemente attive?
E' sicuramente un errore di applicativo, come una query fatta male o un
picco di traffico improvviso.
Sto cercando, però, di capire come diagnosticare questi problemi
riuscendo ad interpretare il load, non tanto come ottimizzare apache.



la probabilità di capire gli errori applicativi da ps, top o consimili è 
sostanzialmente nulla.
Hai bisogno di osservare un log come dmesg, se ci fosse un log 
applicativo su file o db sarebbe meglio.

 applicativo su file o db sarebbe meglio.
dmesg in questo caso non mi dice nulla, un errore in php non
viene loggato in dmesg.



Oh c'è php?
Modifica il php.ini in modo da alzare il livello di debug e sati a 
guardare il relativo log
(
http://www.php.net/manual/en/errorfunc.configuration.php
)

 e tutti gli 8 core sono completamente occupati.
no. in questo caso lo scheduler, che non usa solo la priorita' ma anche dei
meccanismi di fair queuing, garantisce un pezzo di core a tutti; il sistema
pero' rispondera' piu' lentamente, sempre piu' lentamente all'aumentare di
processi in RUN che sono in attesa del proprio time slice.
viene da se che a questo punto potresti trovare anche altri problemi di
condivisione di accesso alle risorse che poi di fatto ti bloccano
apparentemente la macchina fino a costringerti al reset (es. poca ram:
molti processi generano tanto swap e il sistema passa piu' tempo a swappare
che a eseguire i processi. risultato, macchina apparentemente bloccata.)
quando tu parli di priorita' vuoi significare un processo che deve essere
obbligatoriamente eseguito in quel particolare momento, pena perdita di
dati (es. servizi de/codifica video e audio); solo in quel tipo di casi una
priorita' ha senso.
beh, ha senso rendere nel sistema "meno prioritari" tutti i processi non
direttamente necessari all'erogazione dei servizi, ma questa e' un'altra
storia.

 (
http://www.php.net/manual/en/errorfunc.configuration.php
)
Il php logga in caso di errori, non in caso di siti mattone.
Io non ho errori nella query, ne errori nel codice.
Semplicemente o ci son troppe richieste, oppure il sito è programmato
male. In ambo i casi, php non logga.


 quadcore solo per leggere dei dati?
No.
Un processo può occupare tutte le timeslice disponibili e, se non ci sono 
altri processi, può usarle tutte.
Essendo però ogni processo legato ad un singolo processore (core) può 
usare solo TUTTE le timeslice dello scheduler per quel processore, non 
per altri.
Quindi un processo "impallato" ti può portare, al massimo, il load a 1.
NOTA: top non è lo strumento giusto per fare queste cose perchè di 
default non ti mostra i thread. Usa htop per queste cose.

> non si dovrebbero notare rallentamenti perchè lo scheduler li accoda.
Hai ragione, mi sono espresso da cani.
Per priorità intendevo: "hey, ho bisogno di eseguire qualche cosa, scodami".
In run ci son tutti i processi che chiedono di essere eseguiti.
Lo scheduler, se ha le risorse per farlo (core > processi in R)
li esegue tutti assieme. Se non le ha (core < processi in R)
ne esegue un po alla volta, ovvero in base al time slice.
Un po questo, un po quello e così via, a rotazione.
Di conseguenza, se ho un load a 20, ho 20 processi che negli
ultimi 60 secondi han chiesto contemporaneamente di essere eseguiti.
Se load > core, molto probabilmente questi processi son stati eseguiti
contemporaneamente, se load < core questi processi son stati eseguiti
a spizzichi e bocconi. Più sono i processi, più intasato diventa il 
tutto finchè non devo riavviare la macchina.


 slice.
facciamo un gioco di fantasia:
abbiamo un server, con dentro MySQL, PHP e Apache (MPM-Prefork); per ogni
pagina visitata succede la seguente cosa:
1. il kernel riceve la richiesta rete e la passa ad apache
2. apache crea un processo e gestisce la richiesta
3. il codice PHP apre una connessione a MySQL via network
4. Mysql riceve la query
5. Mysql Risponde
6. Il PHP finisce di elaborare
7. Apache risponde e torna in idle.
ammettiamo di avere molti processi apache e molti mysql a disposizione per
la gestione delle richieste.
ammettiamo che ogni tanto tra i punti 4 e 5 passi una query potente e che
mysql ci metta tempo a rispondere (es. 30 secondi) e che generi al suo
interno dei lock sulle risorse (tabelle, record, ecc)
siccome gestiamo molte richieste al secondo, avremo l'esecuzione dei punti
molte volte al secondo, finche abbiamo workers disponibili; con l'idea che
non appena ci sono piu' workers che core, iniziamo a rallentare.
ora man mano che una richiesta avanza dai punti 1 a 7, il relativo processo
che la gestisce viene messo in WAIT per cui non consuma cpu e load-average
(ma ram si, e bisogna controllare lo swap) per cui non ce ne occupiamo.
supponiamo che abbiamo piu' richieste (decine, centinaia) che sono ferme tra
il punto 4 e il 5, di cui una sola con query lentissima in esecuzione che
ha provocato il lock di tutto il database. 
*tutti* gli altri processi mysql, (e sono decine, centinaia) eseguiranno dei
brevi spezzoni di codice che dicono: [1.dormi per 100ms, 2. mettiti in
esecuzione, 3. controlla i lock, 4. torna a dormire]
quindi avremo molto lavoro per lo scheduler per mettere e togliere dal RUN
moltissimi processi che sostanzialmente fanno attesa. 
cosa succede? 
per ogni mysql che controlla i lock non serve l'intero timeslice che ha a
disposizione, ma solo una frazione, restituendo l'avanzo al kernel; avremo
quindi un carico CPU basso, ma in media moltissimi processi in RUN quindi
il load-avg sale brutalmente.
perche' chiudendo apache risolvi anche se il problema e' in Mysql?
perche' smetti di mandare richieste dietro richieste e dai il tempo a mysql
di terminare le operazioni (o abortirle se del caso) e quindi risolvi il
contention che di base ti provocava il problema.
Attenzione: questa e' una fantasia solo fino ad un certo punto, per me e'
anche esperienza pratica e litigate con i programmatori che non sanno
cos'e' SQL e i database.
io stessa ci ho messo quasi un anno tra analisi, riunioni e politichese per
risolvere il problema senza sbranare la gente che non credeva a quanto
dicevo e chiedevo.
bacioni a tutti e partecipate anche voi al nuovo gioco on-line: sistemisti
contro programmatori. Il risultato e' scontato: vincono i sistemisti !!! :)
per definizione se un programmatore vince e' solo perche' e' un sistemista
mascherato :)
Andrea

 tutto finchè non devo riavviare la macchina.
maggiore e minore messi al contrario ma ok.
Andrea

 riuscendo ad interpretare il load, non tanto come ottimizzare apache.
Io ti avevo detto il contrario.
Secondo me non è un problema applicativo del PHP o di wordpress (puse se 
wordpress ne ha tanti) o del DB perchè:
1) hai detto che il DB è scarico
2) hai detto che PHP (e vedi ogni singolo processo CGI che gira non 
succhia CPU
3) se il 2 non succhia CPU, allora anche Wordpress non succhia CPU.
Ti ho già detto che *a mio avviso* (e la testa ce l'ho sbattuta 
parecchio) pur ottimizzando wordpress, mysql o php, il "TAPPO" è apache.
Tu qui hai un sistema che accoda le richieste e ne riceve più di quante 
riesce a smaltirne e si siede su se stesso.
Al PHP (e di riflesso a mysql) le richieste non arrivano proprio.
Se PHP e mysql non sono carichi, il tappo non sono loro.
Rimane tutto il resto ma se escludi CPU, network e disco, rimane solo 
apache.
Guarda li sopra, metti quel mod_expire che ti ho consigliato e sminchietta 
pesantemente con le configurazioni del prefork (o del worker, se puoi).
Vedrai che la situazione migliorerà.

 sistemista mascherato :)
Si vero.
Il tuo ragionamento non fa una grinza ma non è questo il problema di 
Gandalf.
Il problema qui è il punto 2)


Ma chi ti dice che non ci siano errori?
Un task puň rimanere appeso (al limite) se ci sono problemi di 
sincronizzazione con il db.
Metti sotot trace il db sennň. Vedi quali sono le transazioni che 
occupano piů tempo. Non sapre indicarti la tecnica su mysql, io uso 
oracle e db2.
C'č chi afferma che l'engine di mysql non sia in grado di gestire troppe 
transazioni, magari sei a quel limite.
Oppure stai pensando a dei loop nei programmi?

 il load-avg sale brutalmente.
Ma quindi la mia ultima definizio č stostanzialmente corretta.
In load indica la media su 60 secondi (o 5 minuti o 15 minuti)
del numero di processi in RUN in un dato secondo.
Se lo scheduler riesce ad eseguirli tutti insieme, ovvero ha piů
core dei processi, va tutto ok, se invece i processi superano il
numero di core, il sistema inzia ad accodare, ed accoda finchč
regge.
A forza di accodare o finisco ram (e muore la macchina) oppure
tutto fila liscio anche con load 1000, al massimo collassa un
solo core perchč un singolo processo (eseguito da un singolo
core) lo mette KO per molto tempo.
Se mi ritrovo a gestire 8 di questi processi pesanti,
mi muore la macchina, perchč tutti e 8 i core si ritrovano KO
da fork diversi del singolo processo mattone.
Puotrebbe capitare, perň, che i dischi siano lenti e non tengano
il ritmo. In tal caso, se tutti i miei processi (indipendentemente
dal core su cui vengono eseguiti) richiedessero accesso al disco, lo
scheduler li accoderebbe, il load sale, e la macchina muore,
perchč tutti i processi sono in attesa del disco e lo scheduler non
puň far altro che accodarli.
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito č di fare il possibile per la



Io ci proverei.

 maggiore e minore messi al contrario ma ok.
Cazzo si, mi sto rincitrullendo.
Si, è come dici te.


 pesantemente con le configurazioni del prefork (o del worker, se puoi).
L'ho messo, ma ho fatto un graceful.
Non ho idea se sia partito o no, non credo, appena posso
faccio un restart brutale.


 e non lo è.
MySQL è esterno, non vedo il carico sui dischi MySQL dal server web.
(non lo vedo nel senso che gli strumenti canonici, top, ps, htop etc
ovviamente non danno visibilità di tali dati)


 Oppure stai pensando a dei loop nei programmi?
Loop o codice/query fatto male.
Ma come dice CtRiX, il problema sembra apache, altrimenti
vedrei un carico anomalo a livello di PHP e/o una esecuzione
fortemente rallentatata delle query.
Se mysql non riuscisse a starci dietro, le query passerebbero
da pochi millisecondi a svariati secondi, e scatterebbero i
miei script.
(e comunque, il load a 80/90 che ho postato oggi č riferito ad
un server di posta, che quando legge da disco l'ultimo login
dei clienti, sale a 90 di load poi cala a 0.5)
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito č di fare il possibile per la


 2. apache crea un processo e gestisce la richiesta
Se non ricordo male, si può configurare apache per non aprire un 
processo per richiesta.

 Il problema qui è il punto 2)
allora mi e' sicuramente sfuggito qualcosa della descrizione.
ma l'OP ha inviato un messaggio dove spiega la sua architettura?
Andrea

 Forse ignori cosa significa fare il dump delle query su db... :)
Dolorosamente lo so. Ovviamente solo per qualche minuto.

alef-0 wrote:

andrea: Cliente, vorrei un server nuovo per aumentare le risorse ed
implementare dei meccanismi piu' intelligenti dell'apache del 2002.
Cliente: questo c'e' fattelo bastare che i programmatori dicono che va bene
andrea: grrrrr....
niente di nuovo sotto il sole, come vedi. :)
andrea


Il problmea starà nel fatto che non vuoe pagare i test del sw su server 
nuovo. Offrigli una tariffa competitiva per farli tu, stì test.

 può far altro che accodarli.
si, ma li mette in WAIT perche' sono in attesa disco, quindi il load non
aumenta tanto, pero' ci possono essere altre condizioni a contorno che ti
provocano il blocco apparente (es. in condizioni critiche tenti di accedere
via ssh che era stato swappato via e quindi aspetti molti minuti prima che
le pagine diventino di nuovo disponibili.
per questi casi nei nuovo kernel hanno curato anche lo scheduler dell'IO.
Andrea