V tomto blogu (http://blog.websupport.sk/2010/01/tipy-na-zrychlenie-emailovych-a-webovych-sluzieb-skalovatelnost-mysql/) 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áciou 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.
Pekne, no ja bych jizlive poznamenal ze pokud chcete zvysit vykon databaze nepouzivejte MySQL, ale samozrejme chapu ze je to jakysi trzni standart v tehle oblasti, navic s takto udelanou virtualizaci by se dal taky vymyslet pomerne zajimavy HA system, jak mate resenou HA ted? HeartBeatem nebo ciste mysql prostredky?
Co se tyce mailserveru jasne... CFQ je obecne dost spatny pri zapisovani velkeho poctu operaci/velke granularite operaci, dal by se zvolit i lepsi nez je DEADLINE, ale predpokladam ze desitky tisic dolaru za montavistu nebo SLERT (neboli Concurrent Linux) se vam zrovna platit nechce ... nicmene neuvazovali by jste pro mailovy a vlastne i databazovy server pri obmene hardwaru zkusit treba Movidis server? (www.movidis.com). Je postaveny na RISC procesoru OCTEON ktery ma 16 jader a na operace tohoto typu je jak delany, ma vybornou propustnost a diky velkemu poctu jader a MIPSove architekture umi zpracovavat celkem dost operaci simultalne, ale je pravdou ze jeho hruby vypocetni vykon je nizsi nez intelu, nicmene je otazkou na co potrebujete instrukce vhodne napr. pro vypocet fraktalu na emailovem serveru ;).