Newsgroup: it.lavoro.professioni.webmaster
Titolo: Scovare chi consuma la cpu

Esiste un modo per trovare chi o cosa sta consumando la cpu in un 
webserver? Devo capire se c'è uno script php in particolare che mi sta 
consumando tutta la cpu, ma non posso andare per tentativi disattivando 
parti del sito fino a scovarlo. C'è un qualche modo che possa mostrarmi 
il consumo della cpu per ogni script eseguito da apache e php? (parlo 
di un server linux debian)
 
Grazie
 
 

(parlo di un server linux debian)
 
Ah, allora si può :-D
 
Dovresti fare in modo che ogni processo PHP che parte includa un file
 
<hint> php_value auto_prepend_file /usr/local/bin/checker.php </hint>
 
che registri lo stato attuale di CPU, memoria etc., via ps, usando le
funzioni memory_get_usage() e shell_exec(..ps...-pid=".getmypid()...)
e via register_shutdown_function si assicuri di registrare gli stessi
valori un attimo prima che lo script termini e faccia la differenza -
o la puoi fare tu dopo con calma... anche se così il log raddoppia di
dimensioni (devi registrare prima e dopo).
 
Con le necessarie necromanzie si possono anche aggiungere nel log del
webserver (Apache combined), ma altrimenti va benone spedire tutto al
syslog (non scrivere direttamente su un logfile: la concorrenza ti fa
male, e se usi flock scopri che dentro una shutdown function funziona
solo con il Sole in Sagittario - BTDTGTTS & YMMV).
 
Poi il file prodotto da syslog te lo mantrugi come vuoi, e scopri che
script sono chiamati (number of calls), average load, average memory,
top load, top memory ecc.
 
Io per es. una volta scoprii che non era lo script grosso a fare guai
ma uno script ritenuto innocuo, che in certe circostanze s'inlooppava
terminando solo dopo cinque o sei ruggenti secondi, in cui si fotteva
il ciento pe' ciento di uno dei core, rallentava un ALTRO script e in
tal modo gli dava la colpa :-)
 
Gli script sono bestiacce infide, ecco.
 
Leonardo
 
-- 
Surstangas via akcipitr', la cxeval' fojnumas nur:
Jen vigla damo en brakum', kaj vi pensas pri forkur'?
Do li turnis sin, kaj turnis sin, kaj ekdormis sen singard';
Kaj lin apudis je l' vekigx, soldatoj kaj Barnard'.


 
....
 
Wow! Ottimo consiglio grazie. Lo provo subito su un server di test.
Però ho anche trovato questa guida interessante sull'uso di Xdebug:
http://www.sitepoint.com/faster-php-apps-profile-your-code-with-xdebug/
 
 
 


Se stai usando apache con prefork o itk e PHP come modulo, ti basta 
guardare con top il processo apache che occupa piu` CPU.
 
Certo e` una rogna per script che durano poco, e in questo caso meglio 
seguire il consiglio di Laonardo, ma se hai script che saturano la CPU (o 
che occupano molta RAM) per diversi secondi o anche minuti, con top li 
vedi (solo che appaiono sotto "apache" non sotto "php"). Poi in /proc hai 
tutte le info che ti servono, anche troppe (il che puo` rendere difficile 
scoprire esattamente cosa non va).
 
Altrimenti xdebug, come hai giustamente notato.
 
Bye.

guardare con top il processo apache che occupa piu` CPU.
 
Sì, questo però (e neanche sempre, dipende dalla conf) ti dice solo quale
utente, e dunque quale sito Web, è il responsabile.
 
Perciò se il problema è, "quale dei miei cento clienti fa il guappo", non
c'e' dubbio che sia meglio usare top, anche perche' l'iniezione di script
puo' avere dei side effect mica da ridere.
 
Nel caso "e' il mio sito", top mi dice soltanto il processo di apache, ma
non quale script sta facendo girare (AFAIK). Si può usare strace, ma pure
lì non c'e' una visibilita' chiara su cosa sta succedendo [1].
 
Leonardo
 
[1] si possono vedere casini di rete, chiamate a socket lenti ecc., pero'


 pure lì non c'e' una visibilita' chiara su cosa sta succedendo [1].
 
E` vero.
Mi ricordavo che lo script era tra i file aperti dal processo, ma ora 
vedo solo i file di log di apache e delle pipe, che probabilmente 
comprendono anche il sorgente.
 
Bye.

 pure lì non c'e' una visibilita' chiara su cosa sta succedendo [1].
 


 utente, e dunque quale sito Web, è il responsabile.
 
Unito all'output mod_status sai anche qual è l'URI che sta processando.
 
Ovviamente funziona bene per script che durano abbastanza a lungo.
 
-- 
  Daniele "Vihai" Orlandi
  Bieco Illuminista #184213

"Galerio"  ha scritto nel messaggio news:4e8767d8$1...@news.x-privat.org...

Non devi assolutamente andare a tentativi. E il modo migliore per trovare il 
codice incriminato è procedere per esclusione. Non è nemmeno necessario 
procedere disattivando il sito e riattivando le singole parti fino a 
trovarlo.
Il problema sembra essere saltato fuori da un certo momento in poi, e quindi 
prima di allora tutto funzionava. In conseguenza di ciò è probabile che sia 
qualche codice di terze parti che hai aggiunto successivamente a creare il 
casino.
Devi semplicemente cercare li.
Altre soluzioni vanno pure bene, ma a conti fatti, ti renderesti conto che 
ti porterebbero via maggior tempo.
 

ti porterebbero via maggior tempo.
 
Be'... diciamo che va fatta una stima e, se del caso, un investimento.
 
Su sistemi molto complessi, dove magari non puoi mettere mano nel codice
di terze parti, o addirittura quello e' il codice che SVELA il problema,
ma non CONTIENE il problema (e non puoi dire al cliente "Non posso usare
il suo plugin perché va in conflitto con un errore che ho fatto io nella
mia configurazione", perche' ti risponde "Cazzi tuoi"), può convenire un
maggiore investimento anticipato in cose tipo, appunto, XDebug.
 
Leonardo



Xdebug va bene, ma occhio, montalo su un server di test/sviluppo, 
altrimenti corri il rischio di schiantare il server di produzione.
 
-- 
Paolo De Dionigi

Galerio scriveva il 01/10/2011 :

RISOLTO:
a quanto pare era google che all'improvviso è passato da 10.000 pagine 
scannerizzate al giorno a 80.000 perchè si è messo a passare pure le 
stesse pagine che però avevano in più una query-string.
Ma porc....
Ora ho subito abbassato la frequenza di scansione di google e impedito 
tramite googlewebmaster e tramite robots.txt la scansione di certe 
query-string (cacchio, solo le pagine con ?cid= erano più di 1 
milione!!!!)
E infatti ora il server è tornato a consumi bassissimi.
Persino nel forum considerava due pagine un url con e senza langid 
nonostante abbia impostato per ciascuna pagina il canonical url...
Sto Panda mi ha fatto dannare per mesi.
 
Intanto che c'ero ho abbassato anche la frequenza discansione di Bing, 
che tanto non mi genera traffico ma pure lui era costantemente presente 
nei log.