[vpsFree.cz: community-list] MySQL a maximální zátěž serveru

Wed Aug 6 16:16:31 CEST 2014

S nejvetsi pravdepodobnosti spatne nastavena MySQL. Ta databaze ma slusnej pocet nastaveni, ktery maji vliv na alokaci pameti, coz je alfou a omegou mezi tim, ze to odmaka system jako celek, nebo si podrzi pracovni data v pameti. Nemusi byt nutne spatne navrzene schema, staci spatne pametove nastavit MySQL server a uz to krouha disky, jelikoz my mame na masinach efektivnejsi cache, nez bezne vidite v linuxu na ostatnich fs (mluvim o ZFS ARC), tak ta databaze vyzere o hodne vic CPU casu, nez by musela a az potom, kdyz ani ARC se zprefetchem nijak nevystihuji ten jeji workload, se saha realne na rotacni disky.

Vetsine takovych bordelujicich VPS krouham CPU dolu, aby si lidi tu DB lip nastavili.

Ten manual MySQL neni slozity, navic spousta z tech nastaveni se da vcelku snadno experimentalne overit na edge cases (staci se podivat na nejcastejsi queries + slow query log).

Samotna MySQL query cache je tak rychla, ze nema smysl pouzivat Memcache pro naprostou vetsinu use-cases, kde jsem ho videl do ted, to ma smysl na opravdu velke deploymenty, kde je zatez na cache uz dela takovou zatez na CPU, ze je lepsi cache distribuovat (po siti!). Je jednodussi naucit se nastavit MySQL.

Jedina potencialne pruserova situace nastava, kdyz se casto dela query, ktera bezi dlouho, ale je ulozitelna v query cache a v aplikaci se takova query casto vola.
Nejhorsi je takovymu systemu menit casto data pod zadkem, to je potom spatny navrh schema te db, pravdepodobne programatora, ktery neco takoveho napise, nespasi zadny externi caching, protoze si neumi hlidat atomicnost dat, jak je potreba (experti na to maji asi lepsi vyrazy).

snajpa

Sent from your iPad

> On 06 Aug 2014, at 09:21, Tomáš Valoušek <valy23 at gmail.com> wrote:
> 
> 1) pridat session a "znahodnit" pozadavky neni problem, napr.:
> 
> my $c=1;b
> while ($c < 5000) {
> my $a =  `ab -n 1 -c 1 -H "Accept: text/xml" -C my_session=5a4ed0c68b9595cb1aed93cbd6b1917f6a2b3aef http://xxx.xxx.com/rest/location/event/$c`;
> $c++;
> }
> 
> 2) zapni si logovani vsech dotazu do db. pomalost databaze muze byt zpusobena 
> a) velkym mnozstvim jednoduchych dotazu - videl jsem i katastroficke scenare kdy radek tabulky na vystupu vygeneroval jeden ci vice dotazu do DB - 
> b) malym mnozstvim slozitych dotazu - zde je potreba zkontrolovat dotazy, indexy atd... kazdy dotaz vzit, provest EXPLAIN ANALYZE pokud neco takoveho mysql
> 
> 
> Dne 5. srpna 2014 23:53 Stanislav Kocanda <stanislav.kocanda at vanio.cz> napsal(a):
>> Ahoj,
>> 
>> Apachebench používám pravidelně, ale má to své limity, protože tím jak to dotazuje stále stejnou stránku, tak to většinou zcela pokryje Varnish a výsledky jsou mnohem lepší, než pak realita (potřeboval bych dotazovat náhodně více různých stránek a hlavně bych potřeboval dotazy se sessions, protože velká část provozu pochází od přihlášených uživatelů, které Varnish pochopitelně necachuje).
>> 
>> Na ten Load Impact se mrknu, díky za tip.
>> 
>> Standa
>> 
>> Dne 5.8.2014 23:45, Ondrej Galbavý napsal:
>>> Ahoj,
>>> 
>>> navrhujem ten server zatazit vopred a otestovat konfiguraciu :) Napr
>>> pomocou http://loadimpact.com/ [17] alebo
>>> https://en.wikipedia.org/wiki/ApacheBench [18]
>>> 
>>> 
>>> Ondrej
>>> 
>>> 2014-08-05 23:42 GMT+02:00 Stanislav Kocanda
>>> <stanislav.kocanda at vanio.cz [19]>:
>>> 
>>>> Ahoj,
>>>> 
>>>> díky za odpovědi oběma. Ačkoliv už jsme na aplikaci samotné
>>>> udělali hodně performance-related úprav a cachujeme jako diví,
>>>> ještě stále na ní je co zlepšovat a některé dotazy které
>>>> aplikace vyprodukuje jsou hodně nepěkné. Během srpna máme v
>>>> plánu stav zlepšit, tak uvidíme. Motivován odpověďmi jsme se
>>>> pustil do zlepšování konfigurace MySQL a i když už jsem
>>>> minimálně jednou tento fine-tuning dělal, překvapilo mě, kolik
>>>> toho bylo špatně (hlavně innodb_buffer_pool_size). Takže po
>>>> stránce optimalizací snad budeme připravení lépe než loni. :)
>>>> 
>>>> Nicméně by mě přesto zajímalo, jaké jsou zhruba limity
>>>> našich VPS? Chápu, že to je hodně individuální věc, ale
>>>> alespoň řádově, s průměrnou webovou aplikací v PHP/MySQL a s
>>>> rozumně nastaveným serverem, na jakou zátěž byste si troufali?
>>>> 
>>>> Díky.
>>>> 
>>>> Standa
>>>> 
>>>> Dne 5.8.2014 20:00, Jaroslav Skřivan napsal:
>>>> 
>>>>> Jo, sorry. Napsal jsem jen pulku odpovedi, co jsem chtel. Z
>>>>> pohledu
>>>>> I/O operaci zalezi na tom, ktere to jsou.
>>>>> 
>>>>> Pokud mas hodne zapisu, tak to chce zjistit, cim jsou zpusobene.
>>>>> Pokud je vytvari temp tabulky a nejdou zoptimalizovat, tak je
>>>>> staci
>>>>> presunout do tmpfs a mas klid. Pokud se jedna o zapisy aplikace,
>>>>> tak
>>>>> se da upravit innodb_flush_log_at_trx_commit (pouzivas-li innodb,
>>>>> coz
>>>>> bys mel).
>>>>> 
>>>>> Pokud mas hodne cteni, tak potrebujes vic pameti a trochu
>>>>> prekonfigurovat databazi, aby tu pamet vyuzivala. Idealne tak,
>>>>> aby se
>>>>> vsechna data vesla do pameti, pak mysql pri cteni nebude sahat
>>>>> vubec
>>>>> na disk (akorat po startu, aby si vse nacachovala).
>>>>> 
>>>>> Pak zkontroluj indexy, jestli se spravne pouzivaji a jestli je
>>>>> jich
>>>>> rozumne mnozstvi.
>>>>> 
>>>>> Jarda
>>>>> 
>>>>> ------ Original Message ------
>>>>> From: "Jaroslav Skřivan" <skrivy at skrivy.net [10]>
>>>>> To: "vpsFree.cz Community list" <community-list at lists.vpsfree.cz
>>>>> [11]>;
>>>>> "vpsFree.cz Community list" <community-list at lists.vpsfree.cz
>>>>> [12]>
>>>>> Sent: 8/5/2014 7:47:28 PM
>>>>> Subject: Re: [vpsFree.cz: community-list] MySQL a maximální
>>>>> zátěž serveru
>>>>> 
>>>>>> Hoy,
>>>>>> 
>>>>>> zkus se zamyslet nad nasazenim cachovani - treba do redisu nebo
>>>>>> memcache. V zavislosti na aplikaci se tim da odbourat celkem
>>>>>> dost provozu.
>>>>>> 
>>>>>> Jarda
>>>>>> 
>>>>>> ------ Original Message ------
>>>>>> From: "Stanislav Kocanda" <stanislav.kocanda at vanio.cz [6]>
>>>>>> To: "vpsFree.cz Community list"
>>>>>> <community-list at lists.vpsfree.cz [7]>
>>>>>> Sent: 8/5/2014 7:43:46 PM
>>>>>> Subject: [vpsFree.cz: community-list] MySQL a maximální
>>>>>> zátěž serveru
>>>>>> 
>>>>>>> Ahojte,
>>>>>>> 
>>>>>>> rád bych znal váš názor. Na VPS provozujeme web, který
>>>>>>> má v září docela zásadní špičku v návštěvnosti
>>>>>>> (www.burzaucebnic.net [1]). Loni v září jsme s tím měli
>>>>>>> 
>>>>>>> celkem problémy, jelikož na serveru především MySQL
>>>>>>> způsobovala přetížení na diskovém I/O a server chvílemi
>>>>>>> kolaboval (provoz ve špičce byla cca 4000 pageviews/hodina,
>>>>>>> což mi na druhou stranu nepřipadá nijak závratné
>>>>>>> číslo). Loni jsme to vyřešili jednak pomocí varnishe,
>>>>>>> jednak pomocí úprav samotného webu, kde bylo pár
>>>>>>> setsakramentsky problematických dotazů (dibi a
>>>>>>> zjišťování počtu záznamů...) a nakonec jsme situaci
>>>>>>> stabilizovali. Nicméně momentálně je návštěvnost na
>>>>>>> uvedeném webu zhruba dvojnásobná než loni touhle dobou a
>>>>>>> já mám obavy, co se v září stane, kolabujícímu serveru
>>>>>>> bych se chtěl rozhodně vyhnout.
>>>>>>> 
>>>>>>> Chtěl bych se vás zeptat jakou máte zkušenost s
>>>>>>> maximální zátěží VPS, jaký provoz na "normální"
>>>>>>> PHP/MySQL aplikaci v pohodě zvládne a co už je problém?
>>>>>>> Přemýšlel jsem o tom, že bych si pořídil ještě jednu
>>>>>>> VPS a provozoval na ní pouze MySQL, ale nevím, jestli by to
>>>>>>> bylo dobré řešení, jelikož by to zase zatížilo síť a
>>>>>>> asi by to bylo v průměru pomalejší (i když
>>>>>>> předpokládám že nody jsou navzájem propojeny hodně
>>>>>>> propustně). Co si o tom myslíte?
>>>>>>> 
>>>>>>> Díky!
>>>>>>> 
>>>>>>> Stanislav Kocanda
>>>>>>> 
>>>>>>> -- Mgr. Stanislav Kocanda
>>>>>>> jednatel společnosti Vanio Solutions s.r.o.
>>>>>>> 
>>>>>>> telefon: +420 776 643 433 [2]
>>>>>>> e-mail: stanislav.kocanda at vanio.cz [3]
>>>>>>> 
>>>>>>> skype: kocandas
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> Community-list mailing list
>>>>>>> Community-list at lists.vpsfree.cz [4]
>>>>>>> http://lists.vpsfree.cz/listinfo/community-list [5]
>>>>>> 
>>>>>> _______________________________________________
>>>>>> Community-list mailing list
>>>>>> Community-list at lists.vpsfree.cz [8]
>>>>>> http://lists.vpsfree.cz/listinfo/community-list [9]
>>>>> 
>>>>> _______________________________________________
>>>>> Community-list mailing list
>>>>> Community-list at lists.vpsfree.cz [13]
>>>>> http://lists.vpsfree.cz/listinfo/community-list [14]
>>>> 
>>>> _______________________________________________
>>>> Community-list mailing list
>>>> Community-list at lists.vpsfree.cz [15]
>>>> http://lists.vpsfree.cz/listinfo/community-list [16]
>>> 
>>> 
>>> 
>>> Links:
>>> ------
>>> [1] http://www.burzaucebnic.net
>>> [2] http://mail.vanio.cz/tel:%2B420%20776%20643%20433
>>> [3] mailto:stanislav.kocanda at vanio.cz
>>> [4] mailto:Community-list at lists.vpsfree.cz
>>> [5] http://lists.vpsfree.cz/listinfo/community-list
>>> [6] mailto:stanislav.kocanda at vanio.cz
>>> [7] mailto:community-list at lists.vpsfree.cz
>>> [8] mailto:Community-list at lists.vpsfree.cz
>>> [9] http://lists.vpsfree.cz/listinfo/community-list
>>> [10] mailto:skrivy at skrivy.net
>>> [11] mailto:community-list at lists.vpsfree.cz
>>> [12] mailto:community-list at lists.vpsfree.cz
>>> [13] mailto:Community-list at lists.vpsfree.cz
>>> [14] http://lists.vpsfree.cz/listinfo/community-list
>>> [15] mailto:Community-list at lists.vpsfree.cz
>>> [16] http://lists.vpsfree.cz/listinfo/community-list
>>> [17] http://loadimpact.com/
>>> [18] https://en.wikipedia.org/wiki/ApacheBench
>>> [19] mailto:stanislav.kocanda at vanio.cz
>> 
>> _______________________________________________
>> Community-list mailing list
>> Community-list at lists.vpsfree.cz
>> http://lists.vpsfree.cz/listinfo/community-list
> 
> _______________________________________________
> Community-list mailing list
> Community-list at lists.vpsfree.cz
> http://lists.vpsfree.cz/listinfo/community-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.vpsfree.cz/pipermail/community-list/attachments/20140806/f0f14edd/attachment-0002.html>