Tipy na zrýchlenie emailových a webových služieb + škálovatelnosť MySQL


  • Zdieľať na Google+

V tomto blogu vam prinášame niekoľko tipov ako vylepšiť výkonnosť služieb (web, maily, db) bez potreby zháňať výkonejšie železo. A to všetko iba jednoduchými nastaveniami. Berte a vychutnávajte :).


Zlá škálovatelnosť MySQL

MySQL databáza má v niektorých prípadoch veľmi zlú škálovatelnosť. Nedá sa jednoducho vždy zvýšiť kapacita výkonu iba upgradom hardwaru na ktorom beží.
V našom prípade má MySQL problém s veľkým množstvom tabuliek, ktoré sa používajú a zamykaním table_cache v MySQL. Thready čakajú veľa času na otvorenie tabuliek (kým neuvoľní zámok iný thread). Keďže nastaveniami MySQL sa to vyriešit nedá, jediné riešenie je rozloženie záťaže na viac MySQL serverov na virtuálnych serveroch.
Postup je jednoduchý: reboot serveru do XEN verzie kernelu. S XEN verziou máme možnosť dynamicky spúštať virtuálne servery zároveň s hlavným systémom. Následne môžme po častiach popresúvať databázy z hlavnej MySQL na dalšie virtuálne servery.

Jeden z problémov ktoré sa vyskytli, bola chyba v XEN kerneli debianu, ktorá ešte nebola opravená v hlavnom repozitári.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516479

Odlahčenie záťaže databáz

Monitorujeme sql query bežiace na MySQL serveroch a hľadáme neoptimalizované query ktore zbytočne zaťažujú server. Ak objavíme nejaký problém, kontaktujeme zákazníka. V niektorých prípadoch aj pomôžeme s optimalizáciu sql query. Na grafe je vidieť klesnutie záťaže na databázovom serveri po oprave query nad veľkou tabuľkou s problémom ORDER BY RAND(). Graf ilustruje ako môže záťaž na serveroch ovplyvňovať zlý kód aplikácie (query do db).

Order by rand

Bližšie informácie o probléme ORDER BY RAND() http://www.titov.net/2005/09/21/do-not-use-order-by-rand-or-how-to-get-random-rows-from-table/

Často sa nás pýtaju klienti, či ich server unesie vysokú návštevnosť, tisícky zobrazení a podobne. Návštevnosť je dôležitá, ale keď je aplikácia zle naprogramovaná, nepomôžu vám ani najvýkonejšie servery. A platí to aj presne naopak. Pri pekne odladenom a vychovanom kóde, vám bude stačiť aj virtual s pár MB Ram.

Email služby

Dávnejšie v lete sa nám podarilo znížiť zaťaženie emailového serveru zmenou I/O schedulera z CFQ na DEADLINE. CFQ scheduler ktorý rovnomerne rozdeľuje diskové operácie, ktoré volajú procesy začal robiť problémy pri veľkom počte procesov v systéme, ktoré čítali/zapisovali veľa malých súborov. Po zmene schedulera na DEADLINE sa výrazne zlepšila rýchlosť emailových služieb. DEADLINE scheduler používa 4 I/O fronty a zoraďuje čakajúce requesty aby zvýšil I/O priepustnosť. Je výhodné ak prevláda jeden typ záťaže. Na grafe je pekne vidno, ako to znížilo zaťaženie.

deadline

Momentálne už emailové služby obsluhuje iný, výkonnejší server.

Web služby

Rýchlosť webových služieb unlimited a custom hostingu sa zlepšila po ugprade webserverov z distribúcie debian etch na verziu lenny a kernelu na verziu 2.6.31, ten prináša lepší readahead algoritmus pre I/O operácie. Taktiež bola opravená chyba v driveri pre raid radič, ktorá spôsobovala spomalenie diskových operácií pri vyššej záťaži. Na grafe môžete vidieť zníženie loadu na webserveroch po aplikovní novej verzie kernelu.

web

Komentáre

  • Ján Jaďuď
    Odpovedať
    Autor
    Ján Jaďuď

    Nice nice .. strasne ma tesi, ze MySQL uz bude behat lepsie .. uz len taka pohorsujuca otazka .. order by rand() .. to niekto pouziva?!

    • WebSupport
      Odpovedať
      Autor
      WebSupport WebSupport

      s konstrukciami ORDER BY RAND() a pod sa stretavame pomerne casto. Pouzivatelia si neuvedomia, ze SQL dotaz, resp. datovy model databazy ktory im bezi dobre v malom, nemusi byt pri vyssich cislach vobec efektivny.

    • freezy
      Odpovedať
      Autor
      freezy

      pouziva sa to hlavne pri malych tabulkach
      a ak je programator neskuseny tak to bohuzial pouzije aj pri velkych =(

  • Jano
    Odpovedať
    Autor
    Jano

    Pekny clanok, takych by mohlo byt viac kde su tipy a triky 🙂 trosku ot, ale aj tu som si vsimol, ze su pouzite nejake grafy, aky je na tvorenie takychto grafov dobry nastroj?

    • michal.truban
      Odpovedať
      Autor
      michal.truban

      na tieto grafy pouzivame opensource monitorovaci soft: http://www.zabbix.com a mozeme ho len odporucat

      • Jano
        Odpovedať
        Autor
        Jano

        aha, dik. Pozeral som si od toho manual a vsimol som si tam ze je to riesene cez web rozhranie, ci to je len nejaky doplnok a inac to vsetko funguje cez konzolu?

        • michal.truban
          Odpovedať
          Autor
          michal.truban

          ono to treba nainstalovat podla manualu a potom si grafy a ostatne statistiky mozete pozerat cez web.

  • Robo
    Odpovedať
    Autor
    Robo

    Mna by zaujimalo, ako dokazete identifikovat databazu, ktora sposobuje problem s nevhodnymi queries, resp. databazu, ktora sposobuje zvysenu zataz.

    dakujem

    • WebSupport
      Odpovedať
      Autor
      WebSupport WebSupport

      identifikacia sa robi na zaklade vystupu z programu mtop resp mytop ktory zobrazuje query ktore server vykonava v style programu top(1). vyzera to nejako takto
      http://jeremy.zawodny.com/mysql/mytop/mytop.gif
      z tohto programu sa nasledne daju dane query killnut alebo blizsie analyzovat.

  • Juraj Ziegler
    Odpovedať
    Autor
    Juraj Ziegler

    V MySQL 5.1 rozdelili table_cache na 2 časti a pri určitých vzorcoch správania (ehm, WordPress MU, ehm) to dosť pomohlo.

    Negatávna škálovateľnosť query_cache žial stále pretrváva.