Dotaz: Apache prefork vs worker

[MP]

Ahoj,

resim takovy problem s jednim webem. Debian7, mpm_prefork. Pokud proti tomu pustim ab, siege, tak ta testovana stranka je narocna na vygenerovani tak, ze generovani trva pri 1 klientovi 1.5s. Ten server ma 12 jader a je tam i db. A ted...

1) 10 klientu ~ 10tps, load 14

2) 50 klientu ~ 12tps, load 50+

3) 100 klientu ~ 12tps, load 50+

Kdyz to pustim proti jednoradkovemu php, tak mam stovky tps. Ale zde jsem sekly na 12...Ta stranka je zrejme cpu-bound.

Kazdopadne, jaky bude rozdil proti mpm_worker? Mam totiz podezreni, ze ten zadrhel je prave v tom, ze prefork = klient na serverovy proces, ale v jednu chvili muze jet na jednom jadre jen 1 proces. Jak by se u cpu-bound php choval ten worker? Co googluji, zatim jsem narazil na jedinou zminku, kde nekdo prepnutim na worker dosahl 15->250tps, z dokumentace chovani nevyctu. Drive nez v pondeli nebudu moci ten rozdil porovnat na testovaci vm (pokud najdu zpusob, jak udelat delsi php na vytizeni cpu). Takze, ma nekdo k tomu nejake zkusenosti?

Diky

---

---

Odpovědi

[blb]

Synteticke testy Apache s "jednoradkovym phpkem" se mi nikdy neosvedcili na testovani performance Apache. Nahod alespon zakladni instalaci Wordpressu s nejakym example obsahem a pust na to ab ;)

Pro obecnou aplikaci bych zacal s mpm_event, ktera se snazi resiti overhead spojeny s navazovanim a udrzovanim TCP spojeni. mod_status je tvuj pritel, o performance tuningu Apache je popsana tretina internetu, zbytek vykoumas testovanim.

[cronin]

Ak je generovanie stránky výpočtovo náročné, zmena MPM nepomôže, lebo to, čo zahlcuje server, je generovanie stránky, nie forkovanie procesov webového servera. Zmena MPM z fork-based na thread-based resp. event-based pomôže až pre veľký počet relatívne rýchlo obslúžiteľných requestov.

Prudko neodporúčam slepo nasledovať príklady konfigurácie uvádzané kde-kade na webe, a to vrátane dokumentácie či predefinovanej konfigurácie dodávanej priamo s apačom. Pred časom sme riešili problém s priepustnosťou istého IDM produktu a celé "riešenie" spočívalo v tom, že sme z httpd.conf vyhodili wannabe-fine-tuning nastavenia MPM modulu, ktoré tam boli copy-paste z dokumentácie apača; stačilo ponechať defaultné hodnoty a priepustnosť išla hore 4- až 5-násobne.

Ak máte "performance sensitive" aplikáciu, tak skutočne jediné, čo môžete urobiť, je porozumieť fungovaniu aplikácie zhora až dole, použiť realistické výkonové testy a odstraňovať identifikované úzke miesta. Pritom na odstránenie úzkych miest bude len veľmi vzácne fungovať nejake "fast=true" nastavenie. Pravdepodobnejšie skončíte prinajlepšom reimplemenáciou nejakej kritickej časti a prinajhoršom zmenou architektúry celej aplikácie, aby podporovala horizontálne škálovanie. Takmer vždy sa dá použiť lepší hardvér, ale táto cesta neškálu dobre technicky a najmä ekonomicky.

Princíp "rozdeľ a panuj" je stále jeden z najúčinejších prístupov na spracovanie informácií. Ak je nutné spracovať dané množstvo údajov a vykonať nad nimi dané množstvo výpočtov, tak tú prácu proste musí počítač s konečnými prostriedkami urobiť; fyziku neporazíte, bez ohľadu na to, čo vám tvrdí výrobca hardvéru, poskytovateľ oblačných služieb či váš manažér.

[petr]

generovani stranky trva 1,5s? To delate rucne nekde v indii, nebo pocitate predpoved pocasi pro pristi rok vsude v EU? Misto hledani problemu v apache se podivejte na aplikaci a snazte se vyresit generovani stranky. U nas treba sifrujeme data, x krat se to wrapuje, x krat se to sifruje. Prvni aplikace delala 1 transakci za 5 sekund. Optimalizace udelala 10 transakci za 0,5 sekundy a je to skalovatelny...

[Michal]

Nevíš nic o workloadu a děláš machry. To ale není na tobě nejhorší. Tím je psát někomu, že nemá hledat problém v Apache, když tam pravděpodobně nějaký je. Doporučení: pokud o problematice nic nevíš a chceš jen machrovat pouze na základě tvé věštecké schopnosti, že 1,5s je při jeho workloadu hodně, tak si to nech pro sebe. Zlepšíš tím svět.

Prefork nemá takovou vlastnost, že spustí max. tolik threadů kolik je jader. A už vůbec neomezí počet TPS na počet jader když provádění skriptu je pod vteřinu (jako v případě toho jednořádkového skriptu). Takže buďto je špatně nastavený prefork nebo špatně testuješ

[Jendа]

Tím je psát někomu, že nemá hledat problém v Apache, když tam pravděpodobně nějaký je.

Jaký je problém v Apache, když se stránka generuje 1.5 sekundy a Apache mu i s tím generováním zvládá obsluhovat 1 požadavek na jádro za sekundu?

[petr]

Ano, nasich xx milionu uzivatelu s tebou naprosto souhlasi ze problem bude v apache konfiguraci. Kolik chces mit jader kdyz generovani 1 stranky trva 1,5s? Kolik ti bude trvat obslouzit 1000 lidi na 16 jadrech?

[OldFrog {Ondra Nemecek}]

Spočítejte si, kolik stránek to udělá pokud využijete všechny jádra a generování jedné stránky bude trvat 1.5s. To je základ.

[Josef Kufner]

Pokud ti jde o výkon, tak zahoď Apache a dej tam nginx + php-fpm. Krom vyšší rychlosti ti to ušetří hromady paměti. A hlavně ti bude fungovat poskytování statického obsahu, i když PHP bude zasekané a čekat na volný proces z poolu, neboť nginx funguje v principu jinak než Apache (event-driven jednovlákno vs. blokující se proces/vlákno pro každý požadavek).

Ale i tak, ty tvoje hodnoty jsou divné. Že by prefork byl výrazně výkonější než worker se mi nezdá – prefork je v podstatě worker s poolem na procesy, aby klient nečekal na fork.

Zkus to jinak. Udělej jednoduchý skript se sleep. Prostě <php sleep(1); echo "Bye." ?>. Pokud i tohle bude zasekávat Apache, tak máš problém v Apachi. Pokud se server nezaseká a prostě to postupně odbavuje požadavky N za sekundu, kde N je počet procesů v Apachi/PHP, tak Apache je v pohodě, ale server nestíhá řešit ten skript a asi mu nestačí paměť (nejen v PHP, ale třeba v databázi), takže se uswapuje.

Tak či onak, pokud to je možné, tak ten komplikovaný výpočet vyhoď z generování stránky a předpočítej si to asynchroně vedle. Nebo si předpočítej aspoň něco, aby to pak bylo výrazně rychlejší.

[alkoholik]

Ale i tak, ty tvoje hodnoty jsou divné. Že by prefork byl výrazně výkonější než worker se mi nezdá – prefork je v podstatě worker s poolem na procesy, aby klient nečekal na fork.

Divne jsou tvoje informace. Worker je narozdil od preforku multithreadovy. Z toho plynou diskuze o pravech, kdyz se z nej ma poustet PHP po ruznymi uzivateli, nutnost thread safe knihovnen a podobne.
Ale vykon je uplne jinde nez u preforku.
PS: uz i Apache ma Event MPM.

[Josef Kufner]

Ah, koukám že jsem si worker poplet za nějaký jiný starý kousek. Ono už Apache docela dlouho nepoužívám. Jinak thread safe knihovny jsou v PHP docela potíž a spousta běžně používaných věcí taková není. Proto už worker není výchozí, jak tomu kdysi bývalo, neboť předchůdce preforku byl docela pomalý.

[MP]

Zkusim tu odpoved na vetsinu reakci...

Takze, event zkusit nemuzu, je to apache 2.2. Za druhe, worker zkusit taktez nemuzu, protoze se tim rozbiji nektere aplikace na strane klienta (pokus o prepnuti jiz byl pred 2 lety). Nginx je ted taktez pase, aplikace dost vyuziva htaccess. Vzhledem k nasazeni v kriticke produkci jakkekoliv zmeny musi byt zvazeny 4x.

Co se tyce nastaveni mpm modulu, tak drtiva vetsina konfiguraci je defaultni, pouze se na dobu testu zvedlo MaxClients na 10k (cilem bylo zkusit najit strop). Pri testech byla vyuzita veskera jadra alokovana pro VM. Pripominam, na te same VM bezi i db. Jo a php skript, zobrazujici cestu, kde se nachazi, se pro 50 klientu vygeneruje pri 750tps, aniz by to bylo na loadu vyrazne znat.

Tohle je zhruba vysledek 1 clienta (siege):

HTTP/1.1 200 1.82 secs: 12964 bytes ==> GET /homepage

Nasledne, testy po dobu 120s:

siege -c 50 -t120S -d 0 --no-parse https://.../homepage
Response time:                  3.92 secs
Transaction rate:              12.61 trans/sec
Throughput:                     0.16 MB/sec
Concurrency:                   49.48
CPU Load 53

-c 100
Response time:                  8.12 secs
Transaction rate:              11.95 trans/sec
Throughput:                     0.15 MB/sec
Concurrency:                   97.03
CPU Load 63

ab -c 50 -t 120 -n 100000000 -l https://.../homepage
Concurrency Level:      50
Requests per second:    12.60 [#/sec] (mean)
Time per request:       3968.430 [ms] (mean)
Time per request:       79.369 [ms] (mean, across all concurrent requests)

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        6  146 536.8      7    3394
Processing:   849 3766 644.9   3870    5028
Waiting:      828 3666 629.5   3763    4975
Total:       1060 3912 534.7   3915    6376

Percentage of the requests served within a certain time (ms)
  50%   3915
  66%   4085
  75%   4191
  80%   4241
  90%   4454
  95%   4676
  98%   5060
  99%   5517
 100%   6376 (longest request)
CPU Load 50

Kdyz se k tomu prida pozadavek sefa, ze ta homepage se ma zobrazit XXXx za vterinu (resp, zrychleni infra o Xnasobek) bez ohledu na optimalizace ze strany vyvojaru (idealne by nemeli delat zadne zmeny na zaklade mych zasahu), tak se to komplikuje, kdyz neni znam cas generovani te homepage na jinem HW/technologii a treba nasazeni Varnish cache pro php taky neni trivialni. Proto ten dotaz na rozdil mezi prefork a worker, to je jedine v kratkodobem horizontu mozne zmenit.

[Josef Kufner]

Nginx je ted taktez pase, aplikace dost vyuziva htaccess.

To se nevylučuje. Tu trochu konfigurace lze snadno přepsat.

Pripominam, na te same VM bezi i db.

A co žere víc? CPU? IO? Pusť si htop, přidej sloupeček na diskové IO a sleduj.

Jo a php skript, zobrazujici cestu, kde se nachazi, se pro 50 klientu vygeneruje pri 750tps, aniz by to bylo na loadu vyrazne znat.

Nahoď XDebug, spusť profiler a nech si nahrát, kde to vázne. Jedno načtení stránky ti dá klidně pár desítek MB velký soubor, tak opatrně s tím. KCacheGrind ti pak záznam v souboru přechroupe a poví, co tam vlastně trvá dlouho. Ale tohle je práce pro vývojáře, ne pro admina. I když ti zas nebudou mít data z produkčního serveru, takže jim to asi budeš muset nahrát

[Josef Kufner]

… Vedle XDebug lze ještě zkusit slow log v MySQL. Logují se tam pomalé SQL dotazy. Je to celkem nenáročné na použití.

[OldFrog {Ondra Nemecek}]

Pokud jsem to dobře pochopil, tak při 10 souběžných požadavcích na server dosáhnete přibližně 100%ního vytížení všech jader CPU. Tedy to nejpíše vázne na CPU.

Pak ale změnou mpm modulu nic nevyřešíte! Vázne to v php nebo v databázi. To je potřeba ověřit odděleným profilováním - použijte profilovací nástroj, zjistěte, kde to tráví většinu času a zda to ten čas tráví v CPU, v čekání na IO a kolik to přitom zabere paměti. Pokud to nejvíce času tráví v provádění SQL dotazů, posuňte se do databázové vrstvy a věnujte se SQL dotazů a databázovým indexům, případně nastavení databáze. Pokud to čeká na IO, může být problém v pomalém přístupu k úložišti (např. při zpracování includes v PHP - v prohledávání cest k includování byla velká slabina PHP).

Profilování pochopitelně nemůžete dělat na ostrém provozu, udělejte si klon produkčního serveru. Není vyloučeno, že může být problém i v nějakém vysloveně vadném nastavení na produkčním serveru (zapnutý debug mód, příliš rozsáhlé logování v aplikaci apod.) Zde může na příčinu navést porovnání s provozem čisté instalace systému a aplikace.

Po provedeném profilování můžete buď

1. opravit kód (tedy PHP kód nebo SQL dotazy posílané do databáze nebo indexy v databázi) anebo
2. opravit vadné nastavení systému (pokud tam nějaké je)
3. můžete zátěž rozložit mezi více serverů (podle situace může být dost pracné) anebo
4. můžete pořídit výkonnější hardware (více jader, rychlejší SSD disky pro databázi apod.)

Varianty 2 a 3 můžete udělat i bez profilování, ale je to nouzové řešení „naslepo“. Je mnohem lepší vědět alespoň přibližně, kde je problém.

Pokud chce šéf nějaký výsledek, musíme být schopen oponentury, tj. vysvětlit, kde je problém a čeho je možno v reálu dosáhnout.

[OldFrog {Ondra Nemecek}]

Já furt nechápu, o co ti jde. Když trvá vygenerování stránky 1.5 sekundy, tak co jako čekáš, že s tím sebelepší webserver udělá?

[OldFrog {Ondra Nemecek}]

Přesně tak. Pokud je při generování stránky vytížené CPU, nelze to zrychlit jinak než přidáním dalších CPU nebo zrychlením toho generování. Případně se lze opakovanému generováním vyhnout pomocí nějaké cache.

Spočítat si to není žádná věda - při 8mi jádrech se v ideálním případě bude generovat maximálně 8 stránek současně, takže pokud jedno generování trvá 1.5sec tak se za těchto 1.5sec vygeneruje maximálně 8 stránek a tedy server zvládne maximálně 8 zobrazení za 1.5sec, což je 8/1.5 = 5.33 zobrazení za sekundu. To vše při předpokladu že je dost paměti a že se požadavky vzájemně neovlivňují.

Pokud se html stránky generuje 1.5sec, je to prostě moc. I pro hobby stránku by to bylo moc. Maximální čas bych viděl optimálně pod 100ms - s tím, že je navíc potřeba vyzkoušet, jak se to bude chovat při větším zatížení (zda ten čas při konkurenčním přístupu nevzroste nad únosnou mez).

[MP]

Tak situace se trosku zmenila. Doslo k upgradu CPU (passmark +25% per core, +aes), modifikace VM z 12 na 20core, ram z 64GB na 96GB a vysledky...

1] dump postgresql se zkratil z 2.5h na 1.5h

2] debug databazovych volani na testovane strance - pripojeni se zkratilo na 1/2, celkova doba dotazu zhruba na 1/2~2/3 puvodnich casu (tohle kolisa dle zateze), generovani stranky se zkratilo (dle zateze) pri 1 klientovi z 1.5s na 0.9s.

Tak se pustilo siege/ab...a vysledky se moc nezlepsily (v tomhle pripade je i vliv, ze stroj nebyl odstaven od pristupu zvenci na dobu testovani).

1] 10 klientu ~ 10 tps, load 14

2] 15 klientu ~ 12.36 tps, load 21

3] 20 klientu ~ 12.79 tps, load 30

4] 25 klientu ~ 14.19 tps, load 34, atd., kolisani mezi 12-14

To same zhruba i pres ab. Jeste to zkusim z jineho virtualu, pokud by treba byl nejaky problem na tom, z ktereho se to pousti. Pokud jsem koukal pres htop na load, tak jsou vytizena vsechna jadra (~75% user, ~25% system). Podle htop navic (meni se to) bylo ve stavu Running napr: 13x apache, 4x psql, 1x netdata (mensi priorita). 1x htop, zbytek je Sleep.

Pokud jsem testoval ten 1 radkovy php skript, tak tam je strop zhruba 1100 tps.

0] 5 klientu ~ 400 tps

1] 10 klientu ~ 720 tps

2] 15 klientu ~ 994 tps

3] 20 klientu ~ 1083 tps

4] 25 klientu ~ 1091 tps, atd., kolisani kolem 1100

V tomhle pripade byla vsechna jadra vytizena kolem 50% (~95% user). Pri testech pres ab pri jednom klientovi ten skript probehne za 8~27ms (<90% 8~9ms), pri 15 klientech jiz 47~117ms (<90% 44~69ms).

Je to nejake podivne...

[Josef Kufner]

Co disky? Stíhají?

[Jendа]

To by podle mě nežralo procesor, ale viselo by to v "D" stavu.

[OldFrog {Ondra Nemecek}]

Pokud to mám shrnout - trochu jste upradovali hw a trochu se to zrychlilo. To je v podstatě dobrý výsledek, ale v praxi vám výkon asi nebude stačit - alespoň hádám. Pokud nemůžete masivně povýšit hardware, budete se muset skutečně podívat na tu aplikaci.

Jinými slovy - momentálně nezáleží, na kolik procent se snížily časy při upgradu hw. Pro radikálnější zlepšení odezev musíte zjistit, kde to v aplikaci vázne, zda tam je úzké hrdlo. To pak řešit opravou aplikace ANEBO speciálním nastavením (například doplněním indexů do databáze nebo použitím rychlého SSD disku apod.). Jak už bylo několikrát v této diskuzi zdůrazněno.

[MP]

Masivne zlepsit HW je problem, nepredpokladam, ze by to Debian7 zvladnul z hlediska ovladacu apod.

Momentalne patrame v oblasti aplikace. Udelal jsem totiz takovyhle test (patra se samozrejme ve vice oblastech):

1] php skript volajici time()

2] php skript volajici time() + connect do psql (lokalni) a query select version();

Vysledek?

Na tom problemovem virtualu mame tps (1,2,3,4 atd klienti):

1] 100,175,275,350 ...atd (zde zrejme vliv preforku na strop)

2] 27,50,72,118 ...atd

Podobne se chova i jina VM. Ale, pokud pro otestovani pouzijeme novy navrh infrastruktury (odlisny hypervizor, debian, php atd, relativne stejny virtualizacni hw, ale vm disky jsou tentokrat na nfs serveru), ktery ma oddelene www a psql servery na samostatne VM, tak mame zhruba 2x tolik tps. Samozrejme, zmenily se doby provedeni ruznych db skriptu generujicich stranku (male dotazy zpomaleni, velke dotazy zrychleni). Ten test jsem provedl na zaklade toho, ze jsem si vsiml, ze pri tech testech nad db se www procesy delily o db zhruba pul na pul (vykyvy ruznymi smery), jako kdyby se to proste vzajemne pralo o misto na slunci.

[Jendа]

Masivne zlepsit HW je problem

Hlavně to už moc nejde, jestli už teď tam máš 20 přiměřeně současných jader.

nepredpokladam, ze by to Debian7 zvladnul z hlediska ovladacu apod.

Stejně to budeš muset za chvíli upgradovat, v květnu končí podpora.

Na tom problemovem virtualu mame tps (1,2,3,4 atd klienti):

1] 100,175,275,350 ...atd (zde zrejme vliv preforku na strop)

2] 27,50,72,118 ...atd

Jinými slovy škáluje to lineárně, přesně tak, jak by člověk čekal.

Hele, už nám napiš, co jako očekáváš, že se stane. Prostě generování stránky ti trvá 1.5 sekundy (pro většinu stránek mi to přijde strašně moc, ale tvoji aplikaci neznám) a žádný webserver, CGI ani databáze s tím nic neudělá. Musíš prostě zrychlit to generování - bez znalosti aplikace se těžko radí, je potřeba zvážit, jestli se nepoužívají neefektivní algoritmy, jestli by to nešlo cachovat, jestli by to PHP nešlo zakompilovat do bytecode, a jestli by to nešlo napsat v nějakém rychlejším jazyce než je PHP.

[MP]

No, jsou to servery HP G7 takze moc soucasne to neni. Proto ten problem s Debianem, zvlaste v kombinaci s XENem.

Konec podpory se v tyhle firme neresi (aneb, ahoj HP G3, furt te vidim v provozu).

Prave ze to linearne neskaluje. Kdyz se kouknes vyse, tak pridani 8 jader k puvodnim 12 prumerny tps zvysilo zhruba o 0-2 dle vykyvu...pritom odezvy a zrychleni jsou videt, ale tady proste ne, cekal jsem aspon zvyseni na 16. A ono houby...

Aplikace maji na starosti vyvojari, urcite hledaji jak to optimalizovat, ale vetsi refaktoring? Myslim, ze na to cas jen tak mit nebudou.

Ono jde hlavne o sefa. Chce to proste zrychlit, aniz by do toho museli vyvojari vyrazne zasahovat (to, zda a jak je zaukoloval na optimalizaci me nema zajimat). Jenze dostat to z 12-14 tps na 400+ jen na urovni hw/sw je orisek. Uz ted se pouziva napr. zend cache, ale cachovat cele stranky na urovni reverzni proxy, to prave nejde, jsou individualizovane.

Je mi jasny, ze vykouzlit to nepujde.

[Max]

Tyjo, to už je fakt stařešina, ty G7 jsou už dávno za zenitem. To je minimálně 6 let starý hw.
Každopádně jak už tu někdo psal, díval jsi se i na db? Osobně jsem řešil třeba pomalost jednoho projektu, kde sice cache na php částečně pomohlo, ale největší brzda byla stejně v db. Chyběl tam jeden index a rázem se zvednul výkon app stonásobně. Prostě monitorovat slow query a další věci spojené s db.
Zdar Max

[MP]

Aplikaci resi vyvojari, ja nemam sanci poznat, zda nekde neco chybi. Nemas zkusenosti, jak se chovala nejaka apka, pokud byla db presunuta na oddeleny treba vm? Misto aby bylo vse v jednom. A pripadne, podle ceho treba vybiras cpu do virtualizacnich masin, predpokladam, ze ani vam stroje nezapujci na test pred nakupem. Ja tu krome g7 mam uz jen g8 a supermicro x10, ale ty jsou ohledne cpu zvoleny jako backup/storage.

[n]

Ta aplikace, zcela evidentne, neni v tuhle chvili schopna naskalovat tak, jak po tobe chteji.

Nez budes pridavat desitky jader a kupovat silnejsi servery, je treba se podivat na to, proc trva jeden pozadavek 1500ms.

My tu aplikaci samozrejme nezname, takze ti nemuzeme poradit co presne zpusobuje, ze je tak neskutecne pomala.

Z toho mala informaci, co sem posilas se zda, ze te, asi, nejvic trapi vytizeni CPU, uzs ale nenapsal, nebo jsem to prehledl, co to CPU zere - Je to PHP nebo databaze (Zda se ze asi pouzivate postgres, je to tak?)

• Jak moc muzes ten postres prekonfigurovat?
• Muzes na nem povolit statement logging?
• Muzes si do nej pridat pg_stat_statements extenzi?
• A pokud ne, mas testovaci instanci, klidne radove mene vykonnou, ale pokud mozno se stejnymi daty, kde neco z toho muzes?

[MP]

Rekonfigurace - relativne dost, pokud je potreba, ale je hlavni sezona toho projektu, tak je lepsi zasahy omezit

Statement - je povoleny

Extenze - mohlo by jit , jen s ni neumim pracovat (jsem systemak, ne db expert)

Testovaci instance - kdyz to sandboxuju pres fw, tak jsem schopny ji vytvorit z backupu, jen nam dosly xenove masiny :) tezke odhadnout, jak to ovlivni pouziti kvm masin...

Dik za tip. Tohle by aspon mohlo ukazat na pripadny problem s postgresql. Kdyztak to zkusime na jinem projektu, dost je jich zalozenych na stejnem zaklade.

[n]

Tak zacit muzes jiste tim ze se konecne podivas jestli ten procesor drti PHP nebo Postgres, skoro me to zacina zajimat. Zkus se na ten top podivat poradne a nestyd se nam to tajemstvi vyjevit.

Kdyz uz mas povolene ty statistiky, tak se pojdme podivat, jestli nekde nemuzeme pojmout podezreni, ze chybi index. To udelame tak, ze so podivame nad jakymi tabulkami se dela vic sekvencnich scanu, nez kolikrat se pouziva index scan:

SELECT relname, seq_scan-idx_scan AS too_much_seq, CASE WHEN seq_scan-idx_scan>0 THEN 'Missing Index?' ELSE 'OK' END, seq_scan, idx_scan FROM pg_stat_all_tables WHERE schemaname='public'  ORDER BY too_much_seq DESC;

Ma to samozrejme vady - 1) ne vzdycky je sekvencni scan spatne - Kdyz si to uplne zjednodusime, cim mensi tabulka, tim min vadi, az je rychlejsi nez index a 2) ze tady vypada tabulka "dobre", neznamena, ze se s ni vsude pracuje velmi a spravne, jen dotazy z homepage potrebuji ten sekvencni scan a trvaji dlouho. Poucka: U tech tabulek co vypadnou jako podezrele se podivej na velikost, kdyz velke, (mozna) spatne.

Nezapomen, ze ten dotaz, tak jak je napsan, se diva jen na tabulky z public schema, pokud pouzivate pro tu databazi co nezname jine, musis ho nalezite upravit.

Taky nezapomen, ze ta aplikace bezi, v tech statistikach zdaleka nemas jen data od dotazu generovanych strankou, ktera te zajima.

Kdyz uz v tom budes, muzes se jiste cvicne podivat, jestli ti taky nejake indexy neprebyvaji, coz muze zpomalovat zapis (Pokud te chapu, je to nejaka homepage, takze toho asi moc nezapisuje a tohle je nam jedno, ale co uz, aspon uvidime, jak moc to vyvojari resi)

SELECT indexrelid::regclass as index, relid::regclass as table, 'DROP INDEX ' || indexrelid::regclass || ';' as drop_statement FROM pg_stat_user_indexes JOIN pg_index USING (indexrelid) WHERE idx_scan = 0 AND indisunique is false;

A sice jsem to povazoval za samozrejmost, ale zminit se to musi - ma ten Postgres zapnute autovacuum nebo je implementovano neco co dela neco periodicky vacuum? Pokud "nevim", zjistit, pokud ne, implementovat. Pokud se ty data meni, bez vacuum se ta databaze s casem zpomaluje az do uplne nepouzitenosti.

Az se probereme timhle, a budes mit pripravene k pouziti pg_stats_statements podle prislusne jedne stranky dokumentace, kterou si jiste prectes az do konce a uz me nebudes potrebovat, postoupime k pouziti, to pak bude teprve u vyvojaru zabava.

To ze jsi systemak a ne "db expert" je jedno, garantuju ze nic expertniho nedelame a delat ani nebudeme.

[n]

Jeste jedna vec - pokud budes delat tu testovaci repliku, je skutecne naprosto jedno, na cem bude bezet, Xen, KVM nebo virtualbox na tvem notebooku s Windows, jedno jadro a pamet, aby se to vubec pustilo ti pro zacatek uplne staci. Nas nezajima, jestli to bezi 1.5 vteriny a 1 vterinu nebo 1.5 minuty a minutu, ale ten pomer a ten bude temer s jistotou velmi podobny.

[Max]

Pokud je chyba třeba v chybějícím indexu, tak ty nemáš šanci to nijak jinak vyřešit, ať přidáš za hw, co přidáš, vždy to bude pomalý, dokud to na úrovni té db nevyřešíš. V opačném případě s každým větším upgradem hw se ti trochu zvedne výkon, ale nikdy to nebude něco ohromujícího. Prostě takové základní chyby nemají hw řešení.
Takže pokud nejsi nějak extra dobrý db admin, tak řešit pomalost app bez součinnosti vývojářů je trochu nedobré. Minimálně by tam měla být nějaká spolupráce na úrovni konzultací, případně nějakých testů, které samozřejmě nemusí vést k úpravě app.

Já takovou věc řešil jednou a měl jsem celkem štěstí. Zjistil jsem, že chybí cache na php, což vyřešilo část problému, ale největší pak byl právě v db, kde chyběl index. To jsem ale řešil na MySQL, kde jsem logoval pomalé selecty a následně jsem na základě nich zjistil, co v těch tabulkách je a když jsem zjistil, že tam není index, tak jsem ho tam přidal.

Stejně tak jsem znal admina z jednoho webhostingu, který za účelem optimalizací toto dělal na úrovni celého webhostingu. Prostě logoval pomalé dotazy a doplňoval, nebo opravoval indexy v klientských db, aby byl celkově webhosting svižnější.

Jinak u nás mám všechno virtualizováno a plus minus znám režie jednotlivých služeb, takže hw sizing není takový problém.
Jinak já mám G7 vyřazené, v produkci jedu G8 a G9.
Zdar Max

[MP]

Myslis, ze bys mi mohl sjet par techle testu http://openbenchmarking.org/test/pts/phpbench-1.1.2 ? Idealne, kdyby se nasel i nejaky 2.4G-2.6G procesor. Zajima me jen to skore/cas + presna verze cpu/virtualizace pro porovnani. Mne totiz vychazi, ze napr. E5-2430 je o asi 10% pomalejsi nex X5650.

Diky.

[MP]

A jeste treba neco takoveho v php skriptu pres webserver:

echo time();

$connection = @pg_connect("host=localhost port=5432 dbname=template1 user=USERNAME password=PASSWORD");

if($connection !== false) { $rows = pg_query($connection, "SELECT version();"); echo $rows !== false ? 1 : 0; } else { echo 'Spojeni se nezdarilo'; }

pustit treba pres siege/ab na 10s pro c=1.

Diky

[OldFrog {Ondra Nemecek}]

Aplikaci resi vyvojari, ja nemam sanci poznat, zda nekde neco chybi.

Můžeš ale např. logovat pomalé sql dotazy a pak je ukázat šéfovi a vývojářům s tím, že tohle je potřeba opravit. Na to dokonce není potřeba té databázi ani moc rozumět. Předem by ale bylo dobré si ověřit, že ta databáze netrpí nějakým problémem v nastavení (např. že má přiděleno málo paměti, že neprobíhá autovacuum apod.), na to ale už databázi rozumět potřeba je.

[MP]

Tohle je debugovaci nastroj, ktery meri db dotazi primo ve strance:

264.993ms Reported 309 queries 9 connections, 91.597ms

Nejdelsi dotazy <10ms, 90% je <2ms.

TTBF z chrome: 743ms.

ab -c1

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        9   10   0.8     10      11
Processing:   809  826  28.1    834     858
Waiting:      790  810  29.3    820     844
Total:        820  836  27.8    844     868

Ted je tam minimum navstevniku.

[n]

No vidis, prumerna delka query je pod 1 ms, to se bude profilovat primo lahudkove...

Body k vyzkumu:

• Proc se to na jeden HTTP pozadavek musi pripojit 9x k databazi - pokud tomu dobre rozumim, zabije se tim 10+% celkoveho casu na pozadavek, to uz neni uplne malo, ale taky te to nezachrani.
• 309 dotazu na stranku do ktere neustale nekdo busi? To je "dost", ale jestli je to hodne nebo malo ti bez znalosti te aplikace nikdo nerekne. Hint k pochopeni o cem je rec: Proc se homepage Facebooku nacita postupne jak po ni skrolujes? Protoze by byla moc velka, moc by potrebovala data ktera se nedaji uplne predpocitat a moc pomalu by se nacitala.

P.S. Porad me zajima, jestli behem vyroby te stranky server vic trpi kvuli PHP nebo Postgresu.

[OldFrog {Ondra Nemecek}]

Teď by bylo asi zajímavé stejné měření opakovat a současně měřit top a iotop (seřadit procesy dle vytížení, v topu si všímat poměr system versus userspace) - a udělat to pro 10, 50 a 100 návštěvníků (pro porovnání s původním dotazem), cca variace na téma:

ab -c 10  -n10   url...
ab -c 50  -n50   url...
ab -c 100 -n100  url...

Samozřejmě zvážit, zda to chcete nebo nechcete měřit na produkčním provozu (zatížíte ho).

[Petr]

Jinak receno, chces aby byla doprava deti do skoly rychlejsi, ale misto vymeny konskeho povozu za normalni auto do toho naivne cpes dalsi kone. Jednoducha matematika, kolik potrebujes uzivatelu a tps dosahnout? Dosahnes toho se soucasnou aplikaci treba na 32 jadrech? Neznam tvou aplikaci, ale pokud jsi se podival na hw a neblokuje te io, neblokuje te sit, tak se musis podivat na aplikaci a s tim souvisi treba i ten db server (treba mate skvelou aplikaci delajici select * na milionech zaznamu), bez analyzy toho kde ti tech 1,5s spotrebuje nejvice casu se proste nepohnes. Muzes mozna ziskat nejake zlepseni vymenou HW, upgrade OS, pripadne xenu, ale primarni problem zjistis jenom analyzou aplikace kde ti tech 1,5s trva nejvice.

[MP]

To 2x tolik tps se tyka bodu 1]

[OldFrog {Ondra Nemecek}]

Podobne se chova i jina VM. Ale, pokud pro otestovani pouzijeme novy navrh infrastruktury (odlisny hypervizor, debian, php atd, relativne stejny virtualizacni hw, ale vm disky jsou tentokrat na nfs serveru), ktery ma oddelene www a psql servery na samostatne VM, tak mame zhruba 2x tolik tps. Samozrejme, zmenily se doby provedeni ruznych db skriptu generujicich stranku (male dotazy zpomaleni, velke dotazy zrychleni).

No a zkoušeli jste to spustit na čistém železe bez virtualizace? Nějaký současný hardware, rychlé SSD disky a dost paměti? Mohlo by to pomoct odfiltrovat případné problémy způsobené virtualizací, síťovým úložištěm.

[archen]

presne to me jak to tu ctu napadlo: 1. dat to na cisty zelezo 2. zkompilovat php, postgres apache ze zdroju a pohrat si s cflags. zejmena u postgre ze zkusenosti lze dostat cca 15% vykonu navrch, podobne muze (ale nemusi) platit pro php, nevim...

doporucil bych posledni gcc 6, 7 je jeste jankovita kpbila a potrebuje cas. bavime se o par balickach. btw ja bych to postavil na minimalistickym gentoo, pokud to ma slapat a support tam stejne neresite, ale tak to je zas pro vas mozna neakceptovatelny

[OldFrog {Ondra Nemecek}]

Já bych se s kompilací nezdržoval, dal bych to na distribuční balíčky, abych vůbec zjistil, jak to jede na čistým hw a výchozím distribučním nastavení. Těch 15%, které mohu získat kompilací, má smysl řešit až pak - až bude vyřešeno těch 85% výkonu, který se někde ztrácí.

[archen]

ja bych to vyresil hned, 1-2 dny uz me asi neposerou

[archen]

ono to prave dohromady da (mohlo by) taky treba az 25 se zelezem (ale to je spekulace), mozna i vic

[n]

No on to ale ma zrychlit 40krat, ne o 40 %...

[archen]

to je ocividne, bude muset dojit k optimalizaci na aplikacni vrstve, ale proc by vysledku mela infrastruktura jen tupe prihlizet ☺

ja si jdu precist jeste jednou tu story, byl nekde nalezen ten bottleneck?

[MP]

Eh, uz mam dodelany sandboxovou kopii toho virtualu, ale musim chvili pockat, az to vyvojari opravi (jina domena, redirecty atd.), nez se na to budu moci pustit. Krome strace, je nejaky dalsi vhodny nastroj, co by dokazal ziskat nejaka data? Nemyslim na urovni aplikace, ale na urovni systemu. Data z Xdebugu zatim nebudu mit k dispozici.

[OldFrog {Ondra Nemecek}]

Už to tu bylo řečeno hodněkrát - je potřena zjistit vytížení CPU (top, htop: userspace vs. system - jaké procesy?), vytížení IO (např. iotop kdo na IO čeká?), obsazení paměti (top, htop - jaké procesy?), slow query log (dle databáze - kde se databáze nejvíce zadýchává?).

Pozor, xdebug podstatně zpomalí aplikaci, ale pomůže zjistit úzké hrdlo, takže určitě zkusit (ve spojeni s KCachegrind na pár kliknutí). Jak bylo řečeno, logy xdebugu jsou obří, takže testovat s citem , případně debug mód zapnout jen na určitém požadavku (je na to url parametr).

Ideální je toto vše měřit 2x - v okamžiku, kdy systém ještě stíhá (škáluje) a podruhé když už nestíhá (je zahlcený) a porovnat virtualizovaný běh s během na čistém železe. Vyplatí se vám se tyhle postupy naučit a výsledek „zrychlil nám web 100x“ je docela dobrá reference, takže to může být svým způsobem i docela zábavné.