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@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@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@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@skrivy.net [10]>
To: "vpsFree.cz Community list" <community-list@lists.vpsfree.cz
[11]>;
"vpsFree.cz Community list" <community-list@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@vanio.cz [6]>
To: "vpsFree.cz Community list"
<community-list@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@vanio.cz [3]

skype: kocandas

_______________________________________________
Community-list mailing list
Community-list@lists.vpsfree.cz [4]
http://lists.vpsfree.cz/listinfo/community-list [5]

_______________________________________________
Community-list mailing list
Community-list@lists.vpsfree.cz [8]
http://lists.vpsfree.cz/listinfo/community-list [9]

_______________________________________________
Community-list mailing list
Community-list@lists.vpsfree.cz [13]
http://lists.vpsfree.cz/listinfo/community-list [14]

_______________________________________________
Community-list mailing list
Community-list@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@vanio.cz
[4] mailto:Community-list@lists.vpsfree.cz
[5] http://lists.vpsfree.cz/listinfo/community-list
[6] mailto:stanislav.kocanda@vanio.cz
[7] mailto:community-list@lists.vpsfree.cz
[8] mailto:Community-list@lists.vpsfree.cz
[9] http://lists.vpsfree.cz/listinfo/community-list
[10] mailto:skrivy@skrivy.net
[11] mailto:community-list@lists.vpsfree.cz
[12] mailto:community-list@lists.vpsfree.cz
[13] mailto:Community-list@lists.vpsfree.cz
[14] http://lists.vpsfree.cz/listinfo/community-list
[15] mailto:Community-list@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@vanio.cz

_______________________________________________
Community-list mailing list
Community-list@lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list

_______________________________________________
Community-list mailing list
Community-list@lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list