Administrare server open source

Platforma de hosting cu software liber, gratuit, open source.

In orice fel de situatie performanta unui anumit serviciu, exact ca in cazul conceperii unui algoritm, optimizarea si implicit performanta sunt puncte importante. Pe langa viteza de functionare care este intotdeauna binevenita performanta are un rol important si anume poate fi folosita ca „moneda de schimb” sau „solutie de compromis” in cazul in care avem de implementat o aplicatie complexa sau servicii care ruleaza lent. Daca aplicatia proceseaza foarte multe date iar datele sunt preluate dintr-o baza de date lenta timpul general de incarcare va fi foarte mare. Daca in schimb avem un serviciu optimizat, chiar daca aplicatia are nevoie de resurse multe, timpul general de incarcare si procesare a informatiei va fi mai mic.

Optimizarea, indiferent de locul in care este aplicata, este un proces complex care presupune cunoasterea in detaliu a situatiei. La fel si in cazul serverului de baze de date MySQL, optimizarea este complexa si depinde de mai multi factori. Totusi, fara a intra prea mult in detalii, un server de baze de date poate fi optimizat suficient daca luam in calcul cativa parametri:

  • memoria RAM pusa la dispozitie;
  • numarul de procesoare;
  • numarul mediu de query-uri intr-un interval de o secunda;

Pentru optimizarea serverului MySQL trebuie editat fisierul /etc/my.cnf, fisier care retine parametri de functionare cu care vor fi suprascrisi parametri impliciti de rulare. Dupa ce am instalat serverul MySQL, fisierul /etc/my.cnf ar trebui sa fie creat automat continand anumite valori. Pe noi ne intereseaza valorile care apar sub linia [mysqld], valori care tin de functionarea si randamentul serverului.

Performanta unui server de baze de date este afectata cel mai mult de cache-uri si limitarile de memorie. Daca avem o aplicatie care ruleaza in continuu 50 de queryuri diferite, queryurile vor fi rezolvate mult mai rapid daca serverul MySQL isi face un cache pentru rezultat. Daca serverul nu are limitari de memorie bine puse la punct, e posibil ca acesta sa ceara mai multa memorie decat e disponibila pe sistem iar ca rezultat o parte din informatie va fi pusa pe partitia swap pentru ca sistemul de operare sa poata gestiona cantitati mari de informatie, partitie care este mult mai lenta decat memoria RAM.

Pentru ca cele doua aspecte sa aiba valori optime va trebui sa modificam urmatoarele valori:

  • key_buffer_size este directiva prin care ii spune serverului MySQL cata memorie poate rezerva pentru stocarea indecsilor in cazul in care tabelele utilizate folosesc indecsi. Cu cat zona este mai mare cu atat se pastreaza mai multi indecsi care fac cautarea informatiei in tabele mai rapida. Ca regula generala, valoarea trebuie sa aiba intre 25% si 50% din memoria totala care o putem aloca serverului MySQL. Intr-un caz ideal ar trebui sa verificam marimea totala a fisierelor .MYI care sa o folosim ca valoare pentru directiva key_buffer_size.
  • table_cache este valoarea totala a tabelelor care sunt pastrate in cache. De fiecare data cand sunt accesate informatiile dintr-o tabela a unei baze de date, aceasta va fi deschisa iar handlerul salvat intr-un cache. E util sa avem o zona alocata pentru aceste tabele care, daca raman in cache, nu vor fi redeschise in cazul urmatorului query si implicit consumul de CPU va fi mai mic. Valoarea default este 64, valoare care este buna pentru serverele cu putine site-uri gazduite sau pentru serverele folosite exclusiv pentru o singura aplicatie. Daca serverul MySQL serveste cereri pe un server de web hosting in regim shared va trebui verificata variabila „opened_tables” care ne spune cate tabele sunt deschise in momentul respectiv. Directiva table_cache va trebui setata cu o valoare apropiata de media de tabele deschise.
  • thread_cache specifica numarul maxim de fire de executie care pot fi salvate in cache. Ca in cazul tabelelor, salvarea in cache a handlerului unui fir de executie scuteste serverul MySQL de crearea unui thread nou si implicit scade numarul de cicluri CPU necesare. Ca regula generala, thread_cache are ca valoare de doua ori numarul de procesoare sau core-uri disponibile in sistem. Intr-un DualXeon QuadCore de exemplu, valoarea pentru thread_cache ar fi 16 (2CPU * 4 core-uri * 2).
  • join_buffer_size este valoarea maxima care o poate lua o zona de memorie folosita pentru queryuri care nu folosesc indecsi. In general queryurile fara indecsi consuma foarte multe resurse pentru cautare, atat cicluri de procesor cat si memorie. Limitarea acestui gen de queryuri este intotdeauna o idee buna. Valoarea maxima care o poate lua directiva este 4GB pe sistemele pe 64 de biti sau 2GB pe sistemele pe 32 de biti. In practica aceste valori sunt mult prea mari. In general queryurilor fara indecsi nu ar trebui sa li se permita acces la mai mult de 1MB decat in cazuri exceptionale.
  • query_cache_type ne permite sa cream un cache pentru queryurile rulate. Poate lua 3 valori: 0 pentru dezactivarea cacheului, 1 pentru activarea cacheului pentru toate queryurile in afara de cele care incep cu „SELECT SQL_NO_CACHE” sau 2 pentru activarea cacheului pentru orice tip de query. In general valoarea 1 functioneaza fara niciun fel de probleme.
  • query_cache_limit impune o limita pentru fiecare rezultat al unui query care urmeaza sa fie salvat in baza de date. Queryurile al caror rezultat depaseste valoarea impusa nu vor fi salvate in cache. Valoarea depinde de tipul aplicatiilor rulate. In general 128KB e suficient, dar poate varia in functie de modul in care e folosit serverul MySQL si de serviciile care il utilizeaza.
  • query_cache_size este zona rezervata exclusiv pentru salvarea queryurilor. Toate queryurile care sunt mai mici de query_cache_limit vor fi salvate pana la ocuparea spatiului alocat iar apoi vor fi pastrate doar cele al caror cache este accesat cel mai des.
  • tmp_table_size este limita pentru tabelele care urmeaza sa fie create in memorie – ex. urmare a directivei „GROUP BY„. In general tabelele nu ar trebui sa consume mai mult de 16MB.
  • max_allowed_packet este marimea maxima care o poate avea un pachet – o celula a unui tabel. Valoarea ar trebui sa fie echivalentul celei mai mari celule dintr-un tabel in cazul in care se folosesc campuri BLOB. Daca serverul este strict pentru web, sau un server de hosting shared, foarte rar e necesar ca valoarea pentru max_allowed_packet sa fie mai mare de 4MB.
  • max_connections e numarul maxim de conexiuni concurente la baza de date. In cazul unui server LAMP este bine ca max_connections sa fie egal cu numarul maxim de conexiuni care le accepta serverul web. In general pe un server LAMP foarte rar e nevoie e mai mult de 128 de conexiuni concurente.
  • max_user_connections e o valoare care impune o limita de conexiuni la nivel de utilizator, nu la nivel de server cum e in cazul max_connections. Este o setare utila pentru serverele de webhosting shared sau in general pentru serverele de web hosting care folosesc mai multe conturi pentru conexiunea la baza de date. O valoare de 16 ar trebui sa fie suficienta pentru un site cu trafic peste medie.

Bineinteles, optimizarea unui server MySQL nu se opreste aici. Totusi, folosind setarile de mai sus pentru a suprascrie setarile implicite si calculand valorile corecte se poate creste randamentul serverului cu peste 100%.

MySQL

2 Responses so far.

  1. Cristi says:

    De exemplu hi2 are baza de date optimizata?sau trebuie sa fac ce ai scris tu?

  2. Sergiu Tot says:

    Presupun ca si-au optimizat serverele. Oricum, nu strica sa ii intrebi 🙂