2010/12/18 Petru Ratiu <[email protected]>
> 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
>
_relativ_, pentru ca I/O bottleneck e una din cele mai delicate probleme de
performanta din punctul meu de vedere si depinde foarte mult de aplicatia
care ruleaza pe masina respectiva.
> 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
>
cel mai simplu si sigur mod de a verifica cu exactitate daca un system
foloseste swap/paging space ramine vmstat(si/so, pi/po dupa caz).
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).
>
nu numai ca e lent, dar el nu este altceva decit o zona temporara de stocare
a LRU memory pages atunci cind sistemul nu mai are memorie fizica libera.
toate operatiile asupra paginilor de memorie se fac in real memory. Daca
ajunge sa aiba pagini de memorie recente, apare fenomenul de memory
thrashing, un fel de cerc vicios in care paginile sunt mutate in/out in
paging space destul de random, tinind cont ca memoria fizica e consumata in
totalitate.
>
> 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
>
_______________________________________________
RLUG mailing list
[email protected]
http://lists.lug.ro/mailman/listinfo/rlug
