On Thu, 2 Dec 2004, Elena Lazar wrote:
> salut, am un server dell, dual xeon la 2.8 Ghz, cu 2 GB de ram si hdd-s
> scsi care logheaza trafic la clienti in genul unui web trafic monitor.
Extraordinar. Sa-ti traiasca. L-ai udat?
> 1. apar tabele corupte din cand in cand. filesystem e ok, nu sunt
> bad-uri pe disk. coruperea tabelelor se pare ca apare in momente de high
> load. cum serverul de mysql este singurul care interactioneaza efectiv cu
> tabelele, nu inteleg ceva: in mod logic, nu ar trebui sa nu se intample
> asta? e vreo problema cu mysql-ul in general sub high load sau cum?
> inteleg sa mearga mai greu, dar de ce sa se ajunga la tabele corupte?
E posibil ca in conditii de incarcare mare anumite instante ale
serverului de mysql sa inceapa o scriere si sa n-o mai termine (iau
kill, apar intre timp semafoare care le dau peste ochi, etc) sau s-o
termine aiurea. Se mai poate intimpla si ca acele instante sa fie
terminate de kernel.
> dura si un sfer de ora pana se opreste, timp in care upload-ul urca la
> nivele "astonomice": am vazut si:
>
> Load Avg 1023: 1 Times(s)
>
> in timpul cat "moare" httpd-ul, nu mai pot face nimic, evident, decat sa
> ma rog sa moara mai repede.
La ce vaca de masina ai load 1023 e mai mult decit extraordinar
de foarte enorm. Vezi ca ceva ii rupe memoria probabil si/sau hdd-urile
din cauza vreo unui buffer nejustificat de mic. Asta determina de obicei
intrarea in swap, inmultirea instantelor serverului mysql care incearca
sa scrie/citeasca, creste iowait-ul, scade idle-ul pe cpu, se umple
ram-ul si... bum.
> ce cauzeaza acest comportament? am zeci daca nu chiar sute de scripturi in
> php, dezvoltate de diferiti, daca le-as fi scris eu macar stiam unde sa ma
> uit :-)
Probabil acest comportament este cauzat de o situatie
asemanatoare celei descrisa de mine in paragraful anterior. Cum se poate
ajunge aici:
1. tunning prost sau necorelat cu dimensiunile tabelelor pe care
le ai;
2. indecsi creati aiurea pe tabele (fie nejustificat fie
cimpurile pentru care s-au creat indecsi au fost alesi gresit);
3. tranzactii proiectate prost. De obicei aici intra categoria
de tranzactii care necesita o prelucrare (ce dureaza) a datelor citite
intr-un query sau pe baza datelor citite se asteapta un input de la un
utilizator, alta aplicatie, etc.
Tranzactiile proiectate prost duc la urmatoarele, aproximativ in
ordine:
- cresterea numarului instantelor serverului de baze de date ca
urmare a cresterii semafoarelor/locking-urilor pentru citiri, scrieri,
both;
- cresterea iowait-ului;
- cresterea gradului de ocupare a memoriei -> swap ocupat;
- poac.
> CPU states: cpu user nice system irq softirq iowait idle
> total 43.2% 0.0% 13.6% 0.0% 2.4% 208.0% 131.2%
>
> cum poate sa fie iowait 208%?! cum poate fi mai mar de 100%? ce sa inteleg
> de aici? (serverul are activat hyperthreading, os-ul vede 4 cpu-uri).
Cind rulezi top apasa tasta "1". Vei vedea cam cum arata
parametrul iowait pentru fiecare din cele 4 (2*xeon cu HT = 4) cpu-uri
virtuale. Ce vezi matale acolo este suma si ar trebui sa ajungi pina la
400% (e o suma de procente).
> de dba la mysql sunt la inceput si din pacate nu avem un om aici care sa
> fie expert in asa ceva.
Analizeaza:
1. structura tabelelor si indecsii pe ele;
2. query-urile care se termina cel mai greu;
Dupa ce vei avea niste date:
3. indecsii care trebuiesc eliminati si noi indecsi ce trebuiesc
creati;
4. modul de ajustare al query-urilor astfel incit:
a. sa fie mai "slim" in cazul lucrului cu join-uri de
multimi mari;
b. sa foloseasca pe cit posibil indecsii si sa nu faca
interogari secventiale;
5. cum vei putea eventual "sparge" tabelele pe care le ai acum
astfel incit ocuparea cpu-ului/memoriei/resurselor HDD sa fie minima;
6. ce valori trebuie sa aiba parametrii pentru cache la
query-uri, buffere sortari si join-uri, etc.
MySQL 4 ar trebui sa fie ok pentru servere cu incarcare
medie->mare. Cel putin la mine dureaza mai mult un du -shx pe directorul
cu tabele decit un query :)
--
Any views or opinions presented within this e-mail are solely those of
the author and do not necessarily represent those of any company, unless
otherwise expressly stated.
---
Detalii despre listele noastre de mail: http://www.lug.ro/
