| Autor | Zpráva | ||
|---|---|---|---|
| Kajman_ Profil * |
Vypadá to, že se dnes už přestala zobrazovat Yuhůova informační stránka o přetížení a místo toho se zobrazuje.
http://www.levny-hosting.cz/prekroceni-systemovych-zdroju + url domény v parametru. To nám pokazí úspěšně roustoucí grafy Nemůže za ty častější přetížení práce s user_topics aplikovaná od 1.12.2010? Možná bych to mohl o víkendu přepsat, aby to nebylo uložené jako text, ale jako více řádku jednoho uživatele do jiné tabulky typu innodb. Možná by i pomohlo jen update low_priority tabulka_uzivatelu ... Taky jsem si říkal, jestli u dotazu s výpisem jednoho vlákna nezakázat sql_cache, ale tím si vůbec nejsem jistý, ale na týden by se to mohlo zkusit. select sql_no_cache ... from tabulka_postu... Nebo dá se nějak poznat, kde bývá ty poslední měsíce úzké hrdlo? |
||
| Chamurappi Profil |
#2 · Zasláno: 10. 3. 2011, 19:21:49
Reaguji na Kajmana:
„se dnes už přestala zobrazovat Yuhůova informační stránka“ Myslím, že občas se stále zobrazuje, protože tu hostingovou hlášku jsem poprvé potkal už někdy včera dopoledne. Ta hostingová hláška mi mimochodem připadá docela potupná. Návštěvníkům se ukazuje, že diskuse nestíhá a že běží jen na nějakém levném hostingu… „Nebo dá se nějak poznat, kde bývá ty poslední měsíce úzké hrdlo?“ Nevím. Pomohly by ti HTTP logy? Pokud nemůžeme snadno povypínat jednotlivé části, co je zkusit naopak víc zatížit? „Možná by i pomohlo jen“ Mám-li něco změnit v ostré verzi, prosím o trochu specifičtější pokyny. |
||
| Kajman_ Profil * |
#3 · Zasláno: 10. 3. 2011, 21:30:26
Mám-li něco změnit v ostré verzi, prosím o trochu specifičtější pokyny.
To sql_no_cache by se doplňovalo v setup_mysql.php u $n == 7, kdy by místo SELECT poster_id, bylo SELECT sql_no_cache poster_id, ale to si nejsem jistý, jestli nebude kontraproduktivní. To low_priority bych zkusil přidat u nového dotazu. Ale stejně si myslím, že bude lepší ta čtená vlákna ukládat do samostatné tabulky. Tohle by se možná mohlo na ostré mohlo i zakomentovat třeba na týden, jestli to není nový kámen úrazu. Místo low_priority by možná šlo změnit typ tabulek z myisam na innodb, ale to by určitě chtělo předtím všechno zazálohovat a asi i otestovat vliv na výkon. S mysql nemám moc zkušeností. Třeba ještě někdo něco poradí. Pomohly by ti HTTP logy? Asi ne. Kdysi (možná hosting) řekl Yuhůovi, že nejvíc výkonu žere databáze. Z logů se asi nic takového poznat nedá. Jedině pak na lepší emulaci zátěže, když by se dělaly nějaké lokální testy s innodb variantou tabulek. Když roboti dělají 75% procent GET zátěže, možná by se dala zase zvážit přísnější varianta robots.txt, která povolí jen roboty, kteří jsou pro diskusi přínosní. |
||
| Chamurappi Profil |
#4 · Zasláno: 11. 3. 2011, 18:18:34 · Upravil/a: Chamurappi
Koukám, že se nám tu objevil profiler. Je z něj patrné, v čem může být problém?
Ve výchozím stavu je rozbalený, to je uživatelsky docela nepohodlné :-) Edit z 16. 3.: Opravdu to bylo hodně nepohodlné, vyndal jsem si svoji IP ze seznamu, s DB stejně asi nic nenadělám. Reaguji na Kajmana: „Tohle by se možná mohlo na ostré i zakomentovat třeba na týden“ Staniž se. Ovšem nyní těžko posoudíme účinnost jakéhokoliv opatření, když nám hostingová hláška obchází statistiku. Podívám se večer do administrace hostingu, jestli v ní nepřibyly nějaká data vyvozená z té hostingové hlášky. „To sql_no_cache by se doplňovalo v setup_mysql.php“ Na to jsem zatím nesahal, uvidíme, zda ta jedna úprava něco změní. „Asi ne. Kdysi (možná hosting) řekl Yuhůovi, že nejvíc výkonu žere databáze.“ Pak jsme několik let žili v dojmu, že to platí pořád a že se situace zhoršuje, a nakonec z logů Yuhů vyčetl, že nás bombarduje pár robotů, které jsme zakázali a bylo po přetížení. Takže teď asi nevíme nic konkrétního. Sám jsem ale v předvčerejším logu žádnou podezřelou aktivitu nenašel. Nejaktivnější IP adresu měl Googlebot. Když by nestíhala databáze, neprojevovalo by se to spíš celkovou leností, viditelnými SQL chybami a timeouty? Nezdá se mi, že klientské požadavky svádějí se serverem lítý boj o přežití, vypadá to, že je rovnou vykopne vyhazovač. Bez čekání. |
||
| Kajman_ Profil * |
#5 · Zasláno: 11. 3. 2011, 18:31:25
Chamurappi:
„Koukám, že se nám tu objevil profiler“ Kde? Já vím jen o tom čase generování stránky v #time, ale to tam je už dávno. Profilery často zatěžují server ze všeho nejvíc. „Nejaktivnější IP adresu měl Googlebot.“ Zrovna ten jde ve webmaster tools ručně poladit, aby nebyl tak aktivní. Teď tam tuším uvádí průměrně nějakých 15 000 požadavků denně. Teď bych to zkusil pár dní nechat jen se tím zakomentovaným ukládáním navštívených vláken. |
||
| Str4wberry Profil |
#6 · Zasláno: 11. 3. 2011, 18:45:27
Profiler se zobrazuje od včerejška jen v sandboxu vašim IP adresám. Pokud je tu Kajman z jiné IP, než ze které zakládal toto téma, tak ho nevidí.
|
||
| Kajman_ Profil * |
#7 · Zasláno: 12. 3. 2011, 10:51:20
Str4wberry:
Nastav tam prosím raději ip z [#5]. Díky |
||
|
Časová prodleva: 3 dny
|
|||
| Kajman_ Profil * |
Chamurappi:
„Podívám se večer do administrace hostingu, jestli v ní nepřibyly nějaká data vyvozená z té hostingové hlášky.“ Našel jsi tam něco? Případně, nejsou kódy přetížení (možná 503) v přístupových lozích? |
||
| Chamurappi Profil |
#9 · Zasláno: 15. 3. 2011, 01:12:15
Reaguji na Kajmana:
Žádné počítadlo zobrazení stránky o přetížení tam není. Jsou tam nějaké grafy využití prostoru na disku, procesoru a databáze, ale nic rozumného jsem z nich nevyčetl. Zítra je sem hodím. Zaujalo mě na nich jen to, že využíváme tři a půl GB z dostupného gigabajtu prostoru a že v prosinci začal výrazněji růst objem přenesených dat, až se dostal na současný historický rekord. „nejsou kódy přetížení (možná 503) v přístupových lozích?“ Nejsou. |
||
| Chamurappi Profil |
#10 · Zasláno: 15. 3. 2011, 19:15:45 · Upravil/a: Chamurappi
Přináším slíbené obrázky zátěže serveru a databáze.
# Zátěž serveru
# Zátěž databáze
# Přenesená data za posledních čtyři a půl roku
Zabrané místoAsi nezajímavé. Jsou to nepřetržitě rostoucí 3 GB, zaplněné převážně zapakovanými a zvenku nepřístupnými HTTP logy od července 2007 do teď.AWStatsModerátoři najdou v moderátorském doupěti odkaz na statistiky z logů.Doporučuji k nahlédnutí i moderátorům, kteří se o přetížení nezajímají. Prosinec 2010 je nějaký rozbitý, ale jinak jsou tam kompletní data od konce května 2010 do teď. Počty přístupů, odkazující stránky, hledaná slovní spojení… |
||
| Davex Profil |
#11 · Zasláno: 15. 3. 2011, 22:29:18 · Upravil/a: Davex
Vyskočilo mi přetížení během prohlížení statistik, kde není žádná databáze ani PHP, takže z toho odvozuji, že přetížení nezpůsobuje databáze, ale možná velký počet HTTP dotazů najednou.
Zatím mě napadlo jen zapnout kešování favicony, která má teď nastaveno defaultní max-age=0. Možná by se tak trochu ušetřilo.
ExpiresByType image/x-icon A30000000 |
||
| Kajman_ Profil * |
Pokud je trochu rezerva u vytížení cpu, ale jsou atakovány hraniční limity pro přenos dat, určite stojí za test zapnout mod deflate i pro text/html. Nyní sice není ani pro css a js, ale Yuhů byl tenkrát pro zapnutí.
* Compressing http://diskuse.jakpsatweb.cz/templates/djpw.js could save 87.4KiB (70% reduction).
* Compressing http://diskuse.jakpsatweb.cz/templates/djpw_jush.js could save 67.9KiB (64% reduction).
* Compressing http://diskuse.jakpsatweb.cz/ could save 23.6KiB (81% reduction).
* Compressing http://diskuse.jakpsatweb.cz/templates/djpw.css could save 12.7KiB (71% reduction).
* Compressing http://diskuse.jakpsatweb.cz/templates/djpw_jush.css could save 2.0KiB (75% reduction).
* Compressing http://diskuse.jakpsatweb.cz/statistika.js could save 624B (55% reduction).
* Compressing http://diskuse.jakpsatweb.cz/reklamy/reklama.js could save 470B (44% reduction).Jinak z těch mysql grafů to vypadá, že ty updaty posledních navštívení vláken mohly docela databázi zahulit. Asi hlavně proto, že se prováděly i pro nepřihlášené uživatele. Myisam tabulky, co jsou teď používány, jsou vhodnější tam, kde se hodně čte a málo zapisuje. Ale pro tuhle věc už můžou zamykáním celé tabulky brzdit. Z grafů přístupů je nejspíš pěkně vidět benevolentnější robots.txt od září 2009. Ale ty grafy se těžko porovnávají, když mají každý den jiný rozsah. Co prozatím google botovi ponížit přes webmaster tools prodlevy před jednotlivými požadavky? (V awstats není v robotech seznambot, ale podle přístupů dle ip, má seznambot společně s jeho beta variantou nad googlebotem, navrch. Třeba by Yuhů mohl nastavit, aby generovaly zátěž spíše v nočních hodinách;) |
||
| Chamurappi Profil |
#13 · Zasláno: 16. 3. 2011, 01:01:47 · Upravil/a: Chamurappi
Teď jsem doplnil denní grafy přenosů, kde jsou i počty požadavků a vytížení CPU. (Dříve jsem si jich v administraci nevšiml.)
Reaguji na Davexe: „zapnout kešování favicony, která má teď nastaveno defaultní max-age=0“ Dobrý postřeh. Obzvláště, když tu těch ikon máme přes 30. Kešování zapnuto. Počet HTTP dotazů bychom také mohli snížit snížením počtu obrázků, jak kdysi navrhoval tiso. Reaguji na Kajmana: „určite stojí za test zapnout mod deflate i pro text/html“ Zkusil jsem ho nyní zapnout pro HTML, CSS i JS. „Z grafů přístupů je nejspíš pěkně vidět benevolentnější robots.txt od září 2009.“ Vskutku. Ale nelituji toho, roboti jsou kamarádi, i když nás občas přizabíjí :-) „ty grafy se těžko porovnávají, když mají každý den jiný rozsah“ Nic lepšího z toho nevymáčknu. Zkoušel jsem, jestli ten graf-generující skript nevezme jako parametr i měsíc, když umí roky a dny. Marně. Kupodivu ale umí vygenerovat věrohodně vypadající graf pro budoucí den, netuším, odkud bere data :-) „Co prozatím google botovi ponížit přes webmaster tools prodlevy před jednotlivými požadavky?“ Nejprve bych počkal, jaké dopady budou mít dnešní změny. |
||
| Joker Profil |
#14 · Zasláno: 16. 3. 2011, 08:01:33
Davex:
„Vyskočilo mi přetížení během prohlížení statistik, kde není žádná databáze ani PHP, takže z toho odvozuji, že přetížení nezpůsobuje databáze, ale možná velký počet HTTP dotazů najednou.“ Není to tak, že po přetížení hosting přestane zobrazovat veškeré stránky? Čili příčinou přetížení nemusela být přímo ta stránka. Alespoň to jsem si odvodil z hlášky na té stránce (že počítadlo se resetuje každých 10 minut či co) |
||
| Davex Profil |
#15 · Zasláno: 16. 3. 2011, 21:45:24
Chamurappi:
> „určite stojí za test zapnout mod deflate i pro text/html“ > Zkusil jsem ho nyní zapnout pro HTML, CSS i JS. JS bych raději nekomprimoval pro Explorer 6 - v kombinaci se Set-Cookie to někdy dělá neplechu. Joker: Ta chybová hláška je matoucí, protože o pár vteřin později se původní stránka zobrazí normálně. |
||
| Kajman_ Profil * |
#16 · Zasláno: 16. 3. 2011, 22:16:32
Chamurappi:
„Obzvláště, když tu těch ikon máme přes 30“ Ale to jsou image/gif, ty to měly nastavené. „Kupodivu ale umí vygenerovat věrohodně vypadající graf pro budoucí den“ Nemají tam převod na absolutní hodnotu, kdy zítra=včera? Nebo mají super analýzu, která to odhadne :-) Dnes se mi žádná stránka s přetížením nepřihodila, tak třeba jen ten deflate pomůže dostat se pod limity hostingu. Možná by se mohlo balit i xml (použité u rss). |
||
| Chamurappi Profil |
#17 · Zasláno: 17. 3. 2011, 01:49:36 · Upravil/a: Chamurappi
Přenesená data jsme gzipováním srazili docela vydatně — doplněn graf z 16. března.
Reaguji na Davexe: „JS bych raději nekomprimoval pro Explorer 6“ Upraveno. V odkázaném vlákně to dělalo neplechu spíš u samotné HTML stránky, ale už jsem viděl i neplechu u JS. Reaguji na Kajmana: „Ale to jsou image/gif“ Ikony jsou opravdu ikony. „Nemají tam převod na absolutní hodnotu, kdy zítra=včera?“ Je to modulo devadesáti. Zítřejší graf vypadá stejně jako 89 dní starý. „Dnes se mi žádná stránka s přetížením nepřihodila“ Mně se bohužel jednou ukázala. |
||
| Chamurappi Profil |
#18 · Zasláno: 18. 3. 2011, 17:31:20 · Upravil/a: Chamurappi
Doplněn graf z dalšího dne.
Reaguji na Kajmana: „má seznambot společně s jeho beta variantou nad googlebotem, navrch. Třeba by Yuhů mohl nastavit, aby generovaly zátěž spíše v nočních hodinách“ Seznambot je ta pravidelná špička okolo páté hodiny ráno. (Pak sem ještě chodí celý den průběžně seznamácký foťák.) |
||
| Davex Profil |
#19 · Zasláno: 18. 3. 2011, 19:56:16
Nemůže se někdo zeptat technické podpory hostingu, který limit diskuse překračuje? Pokud Yuhů platí za hosting tolik, tak bych tam neočekával omezení, která by měla diskusi takto omezovat.
|
||
| Chamurappi Profil |
#20 · Zasláno: 18. 3. 2011, 21:17:29
K té včerejší špičce v 18 hodin se mi už přiznal Kajman, takže ta nám už nemusí vrtat hlavou.
Reaguji na Davexe: Už jsem hostingu psal ve středu skrz formulář, který se používal, dokud ještě nebyl levný. Napoprvé mi to vynadalo, že jsem nevyplnil telefon, po nápravě mi to stejně červeně psalo, že formulář můžu znovu poslat až za 10 minut, což mohlo, ale nemuselo znamenat, že se neodeslal. Počkal jsem hodinu, zkusil to znovu a napsalo mi to znovu, takže fakt nevím, jestli to funguje a z nějakého důvodu na mě dlabou, nebo jestli to nefunguje kvůli nějaké mé chybě, nebo jestli to už dávno celkově přestalo fungovat (žádný statický soubor tam nemá novější Last-Modified než konec dubna 2010). Tak či onak je to chytře vymyšlený formulář brzdící veškeré neurgentní dotazy :-)
Teď jsem jim zkusil napsat na jedinou e-mailovou adresu, kterou uvádějí na svém levném oranžovém webu (k tomu ten přívlastek „levný“ pasuje docela dobře). Pokud ten e-mail dorazí, možná se něco dozvíme. |
||
| Kajman_ Profil * |
#21 · Zasláno: 20. 3. 2011, 00:57:25
Chamurappi:
Jestli budeš cvakat další screenshoty, nechceš je dát k těm minulým, ať se při porovnání nemusí tolik jezdit po stránce? Jinak v pátek jsem možná zase nějakou tu špičku způsobil. Chvíli trvalo, než jsem našel nástroj a způsob, jak těch 800 tisíc blábolů zazálohovat na testy i přes překážky, které tam v podobě nějakých timelimitů nebo čehosi hosting připravil. |
||
| Chamurappi Profil |
#22 · Zasláno: 21. 3. 2011, 10:21:38
Dostal jsem odpověď:
> dobry den, > omlouvame se, ten problem s 503/presmerovanim by mel byt vyresen a zase funkcni u vasi domeny. > jde o pretizeni na zaklade spotrebovaneho cpu. > takze vubec nereste nic s databazi/pocty dotazu, spise php. Tak. Co teď? Jestli tomu dobře rozumím, tak přítomnost profileru a zapnuté gzipování procesoru příliš neodlehčují. Reaguji na Kajmana: „nechceš je dát k těm minulým“ Dal jsem všechny k sobě a doplnil jsem i aktuální databázové. |
||
| Jan Tvrdík Profil |
#23 · Zasláno: 21. 3. 2011, 10:28:11 · Upravil/a: Jan Tvrdík
|
||
| Kajman_ Profil * |
#24 · Zasláno: 21. 3. 2011, 13:02:01
Chamurappi:
„Jestli tomu dobře rozumím, tak přítomnost profileru a zapnuté gzipování procesoru příliš neodlehčují.“ Profiler je teď asi jen v sandboxu a pro tři ip. Ale to je asi nějaký zjednodušený, co hlídá spíš jen dotazy a ne jednotlivé kusy php. Nějaký ten doporučený profiler se může nainstalovat jen u někoho doma a to už by mohlo stačit k nalezení případných problémových míst. (S takovýmto laděním php nemám žádné zkušenosti, s tím asi moc nepomohu, ale třeba tam taky něco málo vykoukám.) Zapnutí gzipu na cpu má asi nepatrný vliv, když třeba porovnám serverové logy z 4.3. a 19.3, kdy je odpoledne kolem 10 000 přístupů za hodinu, tak cpu nevypadá o moho víc zatížené. |
||
| Kajman_ Profil * |
#25 · Zasláno: 23. 3. 2011, 00:54:39
Vypadá to, že kdyby se podařilo přepsat funkci parseTpl lépe, mohlo by to pár procet ušetřit.
|
||
| Chamurappi Profil |
#26 · Zasláno: 23. 3. 2011, 01:11:06
Reaguji na Kajmana:
function parseTpl($tpl) {
$qs = array();
$qv = array();
$ex = explode('{$', $tpl);
$exsize=sizeof($ex); //kaj 22.3.2011 at se nemusi pocitat pokazde
for ($i = 0; $i <= $exsize; $i++) {
if (!empty($ex[$i]) and strpos($ex[$i], '}') !== false) {
$xx = explode('}', $ex[$i]);
if (strpos($xx[0], '[') !== false) {
$clr = explode('[', $xx[0]);
$sp = $clr[1] + 0;
$clr = $clr[0];
if (!in_array($clr, $qs)) {
$qs[] = $clr;
global ${$clr}
;
}
$to = ${$clr}
[$sp];
} else {
if (!in_array($xx[0], $qv)) {
$qv[] = $xx[0];
global ${$xx[0]}
;
}
$to = ${$xx[0]}
;
}
$tpl = str_replace('{$' . $xx[0] . '}', $to, $tpl);
}
}
return $tpl;
}Chce si to někdo zkusit? |
||
| joe Profil |
#27 · Zasláno: 23. 3. 2011, 01:16:50
Ta funkce
parseTpl(...) |
||
| Kajman_ Profil * |
Chamurappi:
„Chce si to někdo zkusit?“ Možná můžeme použít něco jako function parseTpl($tpl) {
extract($GLOBALS,EXTR_SKIP);
return eval("return <<<EOT\n$tpl\nEOT;\n");
}Vypadá to rychlejší, jen by se musely zkontrolovat všechny šablony, zda to s nimi takhle půjde. V téhle funkci je pak nejnáročnější extract, který si můžeme odpustit, pokud do všech šablon přepíšeme zápis {$posterName} na {$GLOBALS['posterName']} doplněno: přidáš prosím časem zase čerstvé grafy? Teď už se dají porovnávat s grafy stránky o přetížení. |
||
| Kajman_ Profil * |
#29 · Zasláno: 23. 3. 2011, 08:19:26
joe:
„se volá při každém načtení stránky?“ Počet volání bývá v desítkách. |
||
| Jan Tvrdík Profil |
#30 · Zasláno: 23. 3. 2011, 09:12:56
Ono ideální by bylo úplně vyměnit ten stávající šablonovací systém (jestli se tomu tak dá vůbec říkat) za nějaký, který se kompiluje přímo do PHP a umí pracovat s parametry, podmínky a cykly. Problém těchto kompilačních systémů je v tom, že je třeba zajistit atomicitu a automatickou invalidaci cache.
|
||
|
Téma pokračuje na další straně.
|
|||
0