2010/12/17 Razvan Deaconescu <[email protected]>:
> Salut!
>
> Îmi puteți indica documentație, link-uri/resurse utile legate de
> profiling/depanarea unui server Apache? Adică informații despre
> rezolvarea unei probleme "Sistemul are un load foarte mare. top/htop
> afișează că procesele Apache consumă procesor și memorie. Cum îmi dau
> seama ce se întâmplă?"
>
> Mă interesează cum acționez în momentul în care văd un load foarte mare
> din cauza serverului Web sau memorie ocupată. De unde îmi dau seama ce
> aplicație este de vină? Este vorba de modulul PHP, Perl sau Python? Doar
> log-urile ar trebui să fie suficiente? De asemenea, dacă la un moment
> dat observ că, prin intermediul serverului web, se trimit e-mail-uri pe
> bandă rulantă, cum identific aplicația web responsabilă?
>
> Până acum am identificat/folosit următoarele "tehnici":
> * verificarea log-urilor
> * strace -p (în procesele Apache)
> * folosirea ab
>
> Există alte tool-uri/tehnici în acest sens?
>
> Întrebarea se generalizează și la alte servere web. Mă interesează "cum
> abordez problema".
Eu unul rar am ajuns sa am nevoie de strace, valgrind, gdb si alte
unelte de "real debugging", dat fiind ca de cele mai multe ori sursa
problemei "reiese".
Best web admin buddy of the year sunt logurile. Pe locul 2 ar veni
ceva gen mod_status, sa poti vedea ce fac copiii de apache. Daca ai
ceva sursa externa de monitorizare (sa zicem ceva cacti/nagios cu
grafice/alerte gen "page load time", "number of httpd children", "fork
rate", sau macar "load average"), poti sa vezi cam de cand a intrat
sistemul in starea atipica si sa vezi daca poti descoperi in loguri
ceva pattern care a inceput de atunci (e drept ca poate nu gasesti
sursa problemei, dar poti avea un simptom mai concret pe care sa-l
poti verifica).
Load mare pe sistem se poate intampla in general din cateva motive:
cpu omorat de aplicatii (caz in care ai user% mare si prin top ai
procese cu %cpu maricel, si R-uri multicele), i/o wait (D-uri multe,
%wa mare) sau forkuri dese (aici nu stiu sa descriu exact un simptom
generic, cred ca sy% ar fi iesit din comun si de pe la un load
suficient de mare in sus, raman zombie destule procese moarte incat
sa te prinzi cine e parintele chinuit).
I/O mare e relativ simplu de lamurit, se ia un proces D si se vede ce
filedescriptori are deschisi (desi in general se cam stie cine e
vinovatul, mai ales daca ai NFS or something :D). Daca nu e vorba de
un FS remote, eu mai folosesc un trick destul de util: sortez top dupa
total time (shift-T) si ma uit daca am kswapd, kjournald, mdX_raidX
samd prin varful clasamentului, caz in care incep sa banuiesc ca se
consuma mult I/O in swapping, scriere pe ext3/4 (scuze, nu stiu cum e
pe reiser sau xfs, si alea au niste kernel threads similare) sau in
sincronizari de raid.
O nota ref. la swapping, o parere gresita des intalnita este ca swapul
e acolo sa fie folosit si sa suplimenteze memoria. No way. E de cateva
ordine de marime mai lent decat memoria fizica si daca ajunge sa aibe
in el pagini recente de memorie (adica nu getty sau mai stiu eu ce
chestii rar folosite, ci aplicatii in use), poti zice doar sarumana ca
n-a intrat oomkiller in actiune si sa vezi cine iti ocupa memoria
fizica (sau sa iei mai mult ram daca e legitima utilizarea).
Daca pe masina aia ruleaza aplicatii scrise de oameni ... sa zicem mai
putin experimentati, utilizarea de multa memorie poate insemna ca
aplicatiile lor lucreaza cu seturi de date de un tonaj care depaseste
permisul lor de conducere a calculatorului (hello 2GB file slurping!),
asa ca e posibil sa se rezolve cu niste capace date in directia
potrivita. Just sayin'...
Ca tot suntem la categoria "am ecdl si nu mi-e frica sa-l folosesc",
adesea problemele astea tind sa migreze via socketul magic de mysql in
mysqld. Paleontologii postuleaza ca din cauza diverselor capace de mai
sus, pe tema "you don't understand unix, gtfo", s-a constatat ca toate
aceste chestii se pot pasa in sql via susmentionatul socket magic pe
care ti s-a dat drept de all privileges. (Cum a dus treaba asta la
"RDBMS are slow, we need NoSQL" lasam la latitudinea cititorului).
Anyway, revenind la oile noastre, daca mysql-ul e pe aceasi masina
(pentru ca cine stie ca exista alte baze de date, stie si ca trebuie
puse in alta parte, nu pe webserver), un show processlist ar trebui sa
prezinte relativ repede un query buclucas si ownerul lui. Se cauta
autorul, se bate bine, problem solved.
Si ca sa ating si intrebarea cu mailurile, se analizeaza ochiometric
coada de mail (cu mailq, exim -bp sau sendmail -bp), se alege tot
ochiometric ceva mail reprezentativ, se citeste (cu postcat -q, exim
-Mv{h,b} si nu mai stiu exact cu sendmail) si se constata cine l-a
trimis si cui. Daca e oarecum legitim (legat de site-ul hostat) se
intreaba casual marketingul "ati trimis voi ceva newsletter?" si daca
se raspunde "a, da, ceva micut la 10k+ oameni", problem solved, poti
sarbatori printr-un scandal.
Daca e ceva cu viagra samd, se cauta frumos cum mama naibii a fost
trimis (poti s-o iei sistematic prin loguri din pid in pid, sa dai in
disperare grep dupa functia mail() prin codul php sau sa mergi la
instinct sa cauti formulare de contact pe site care permit mail header
injection), dupa care poti sarbatori prin alt scandal, in alt
departament (see a pattern here?)
Sorry de lungimea rantului, voiam sa zic ca de cele mai multe ori
problema se poate identifica usor fara aplicarea unei proceduri extrem
de laborioase, cu conditia sa stii ca in mod normal sistemul
functioneaza corect (astfel incat orice abatere are sanse mari sa fie
legata de problema pe care o cauti).
Si one final tip pentru lucrul pe sisteme cu load mare: renice -n -10
$$ in shellul de debugging (cu conditia ca restarturile de daemoni sa
se faca dintr-un shell normal).
--
Petre.
_______________________________________________
RLUG mailing list
[email protected]
http://lists.lug.ro/mailman/listinfo/rlug
