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).
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.
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.
10 odpovedí na “Tipy na zrýchlenie emailových a webových služieb + škálovatelnosť MySQL”
Nice nice .. strasne ma tesi, ze MySQL uz bude behat lepsie .. uz len taka pohorsujuca otazka .. order by rand() .. to niekto pouziva?!
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.
pouziva sa to hlavne pri malych tabulkach
a ak je programator neskuseny tak to bohuzial pouzije aj pri velkych =(
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?
na tieto grafy pouzivame opensource monitorovaci soft: http://www.zabbix.com a mozeme ho len odporucat
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?
ono to treba nainstalovat podla manualu a potom si grafy a ostatne statistiky mozete pozerat cez web.
Mna by zaujimalo, ako dokazete identifikovat databazu, ktora sposobuje problem s nevhodnymi queries, resp. databazu, ktora sposobuje zvysenu zataz.
dakujem
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.
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.