| Autor | Zpráva | ||
|---|---|---|---|
| Lukáš66666 Profil |
#1 · Zasláno: 14. 4. 2016, 14:38:22
Zdravím, dá se nějak snadno zjistit, který skript na webu pracuje nejpomaleji?
|
||
| Enko Profil |
Dá, nastav si časování do jednotlivých segmentů kódu. Např takto:
<?php $cas_hledani_start = microtime(true); //tady bude segment kodu, ktery chces zmerit// $cas_hledani_konec = microtime(true); $cas_hledani = $cas_hledani_konec - $cas_hledani_start; $cas_hledani = substr($cas_hledani, 0, 7); //cas, ktery trval beh segmentu kodu echo "<center><em>Trvalo to: $cas_hledani s</em></center>"; //smaz nastaveni pomocnych promenych unset($cas_hledani_start); unset($cas_hledani_konec); unset($cas_hledani); |
||
| Lukáš66666 Profil |
#3 · Zasláno: 14. 4. 2016, 14:55:02
Enko:
No takovýto způsob znám, ale v tomto případě by to znamenalo umístit ten kód do velkého množství souborů a výsledky někam zapisovat. Těch souborů je tam několik stovek. |
||
| TomášK Profil |
#4 · Zasláno: 14. 4. 2016, 15:10:21
Z logu webserveru. Zpravidla je možné ho nastavit tak, aby logoval i dobu zpracování požadavku.
|
||
| Lukáš66666 Profil |
#5 · Zasláno: 14. 4. 2016, 15:11:03
TomášK:
A poradíš mi jak? V tom se nevyznám. |
||
| TomášK Profil |
#6 · Zasláno: 14. 4. 2016, 19:09:04
Neporadím, ani nevím, jaký máš web server. A musel bych hledat v dokumentaci, jak přesně se to dělá, což dokážeš pravděpodobně stejně dobře jako já - bude to u nastavení logování.
|
||
| Martin2 Profil * |
#7 · Zasláno: 14. 4. 2016, 19:39:15
TomášK:
„Z logu webserveru. Zpravidla je možné ho nastavit tak, aby logoval i dobu zpracování požadavku.“ To je celkem k ničemu. Webserver neví, která část PHP programu vytváří úzké hrdlo. Ani nemůže. Lukáš66666: Co potřebuješ je nějaký profiler. Můžeš zkusit ten, co je součástí extenze Xdebug. Nicméně PHP program málokdy způsobuje pomalé vykonávání požadavků. Většinou je na vině špatně navržená databáze, dlouhé načítání vzdálených prostředků nebo větší datové operace (třeba s obrázky). Když se zaměříš na ně, měl bys problém objevit i ručně. |
||
| Lukáš66666 Profil |
#8 · Zasláno: 15. 4. 2016, 01:04:07
Martin2:
No problém je asi v databázy. Jenže několik měsícu web jel bez potíží s téměř nulovým zatížením a až teď to začalo dělat potíže a přitom v db ani v kodu se nic neměnilo vše je stále stejné i počet návštěv webu za den. Jediné co se změnilo je že zátěž narostla tak, že server padá a pak je několik minut uplně mimo provoz, takže se nikdo na web nedostane. |
||
| TomášK Profil |
#9 · Zasláno: 15. 4. 2016, 01:48:34
A nenarůstá objem dat v databázi tak, že to zpomalilo nějaké dotazy nad únosnou mez? Logováním časů zjistíš stránky, které jsou pomalé. Profilerem taky, o něco detailněji, ale nastavení bude hádám složítější. Ale problém máš s databází, hledal bych tam. Kajman ti radil logování pomalých dotazů, můžeš na chvíli zapnout i logování všech dotazů. Návodů je po webu spousta, třeba tu: stackoverflow.com/questions/6479107/how-to-enable-mysql-query-log (hádám, že to bude mysql)
|
||
| Kajman Profil |
#10 · Zasláno: 15. 4. 2016, 08:08:30
Martin2:
„To je celkem k ničemu. Webserver neví, která část PHP programu vytváří úzké hrdlo.“ Ale Lukáš66666 chtěl hledat „který skript na webu pracuje nejpomaleji“. K tomu je zmíněná úprava logu apache vhodná. Po analýze logu už bude vědět, u kterého skriptu z několika stovek souborů začít s profilováním. |
||
| Martin2 Profil * |
#11 · Zasláno: 15. 4. 2016, 08:27:43
Kajman:
„K tomu je zmíněná úprava logu apache vhodná. Po analýze logu už bude vědět, u kterého skriptu z několika stovek souborů začít s profilováním.“ A Apache mu bystře poradí, že je to index.php nebo bootstrap.php? K ničemu. |
||
| Davex Profil |
#12 · Zasláno: 15. 4. 2016, 19:57:45
Lukáš66666:
„Jediné co se změnilo je že zátěž narostla tak, že server padá a pak je několik minut uplně mimo provoz, takže se nikdo na web nedostane.“ Zjišťoval jsi, proč narostla ta zátěž a z jakého důvodu server padá? Nějaká služba spotřebuje dostupnou RAM, server začne swapovat a ukončovat procesy nebo co se tam děje? Je server dostatečně dimenzovaný a konfigurace služeb přizpůsobená dostupným prostředkům? |
||
| Lukáš66666 Profil |
#13 · Zasláno: 15. 4. 2016, 20:46:41
Davex:
Budu to celé znovu procházet, ale pamět ram spotřebovaná není je zaplněná sotva tak na 10 %. Předtím to zkrátka šlo a aniž by se cokoliv měnilo to najednou padá nebo se to dlouho načítá. A taky mi vrtá hlavou proč jednou je tam 100 lidi a zátěž je uplně minimální a pak je tam 50 lidí a server mele z posledního. Přitom uživatelé mají přistup ke stejným věcem. |
||
| Davex Profil |
#14 · Zasláno: 15. 4. 2016, 21:12:06
Nečekají třeba procesy na I/O nebo nejsou chyby v systémovém logu? Stačí jeden vadný disk v poli nebo vybitá baterka na RAID řadiči.
|
||
|
Časová prodleva: 5 dní
|
|||
| Lukáš66666 Profil |
#15 · Zasláno: 20. 4. 2016, 13:15:04
Davex:
V tom se moc nevyznám. Dá se to nějak monitorovat? Všiml jsem si, že největší zátěž je tam až tak po 18-té hodině i když je tam stejný počet návštěvníků jako celý den. Včera to bylo tak pomalé, že se mi úvodní stránka načítala skoro 5 minut. |
||
| Davex Profil |
#16 · Zasláno: 20. 4. 2016, 19:36:53
Ke zjištění chyb se chodí logy, např.
/var/log/syslog či příkaz dmesg. Na monitorování serveru se hodí třeba programy top, htop, iostat, pidstat, sar, ...
K získání celkového obrazu o stavu systému stačí třeba top, ke kterému zobrazíš nápovědu příkazem man top. Vypadá nějak takto:
Nahoře je zvýrazněno 14.2 wa, což znamená, že se 14.2 % CPU stráví čekáním na I/O operace.
Pokud je níže ve sloupci S písmeno D, tak to znamená, že daný proces čeká na I/O, což je nejčastěji komunikace s diskovým úložištěm.
|
||
| Lukáš66666 Profil |
#17 · Zasláno: 20. 4. 2016, 20:00:05
Davex:
Já používám ten příkaz top. Ale v tom sloupečku S mám skoro všude písmeno S. A ta hodnota wa se aktuálně pohybuje v rozmezí 0.0 - 0.2 , ale u procesu mysql to ve sloupečku CPU před okamžikem vyskočilo na 481 %. Jinak to dneska jede celkem v pohodě oproti včerejšku, ale navštěvníků je tam stejně. |
||
| Davex Profil |
Lukáš66666:
Krátkodobé zvýšení využití CPU procesem nevadí. Pokud by to bylo trvale, tak je pravděpodobné, že MySQL spálí spoustu času nějakým zbytečným počítáním. Třeba nejsou tabulky správně oindexované nebo nejsou optimalizované dotazy a správně se indexy nevyužívají. Další možnost by byla ta, že se o CPU dělíš s dalšími uživateli a nezbyde dostatečný výkon. Kolik má VPS virtuálních procesorů, jaké je load average, a jaká poslední hodnota na řádku %CPU popsaná st?
|
||
| Lukáš66666 Profil |
#19 · Zasláno: 20. 4. 2016, 20:39:40
Davex:
No teď se mi to zdá v pohodě, ale ještě mě napadla jedna věc jelikož to ted jede v pohodě a včera nejelo jestli to nemuže být tím že třeba na vps je na jednom disku spuštěných těch vps víc a tím padem ten disk jakoby nestíhá? Ale to je asi blbost ne? |
||
| Davex Profil |
#20 · Zasláno: 20. 4. 2016, 20:57:53
Lukáš66666:
Ty provozuješ server na jednom fyzickém disku? Tam bych se bál něčeho úplně jiného. Kdyby výkon brzdil disk, tak by MySQL tolik nevytěžovalo CPU. Programem iostat 1 můžeš sledovat, jak je disk vytížen. Případně využití jednotlivými procesy pidstat -d 10.
|
||
| Lukáš66666 Profil |
#21 · Zasláno: 20. 4. 2016, 21:05:46
Davex:
No já totiž netuším jak to u VPS chodí jestli se ten disk sdílí a nebo každému vps je přiřazen samostatný. A v tom co vypisuje ten iostat se nějak moc neorientuju.
|
||
| Davex Profil |
#22 · Zasláno: 20. 4. 2016, 21:34:46
Lukáš66666:
U běžných poskytovatelů se sdílí všechno. Od CPU, přes paměť, disky až po síťové rozhraní. S klesající cenou obvykle roste počet VPS na hostitele. Garantovaný minimální výkon poskytuje málokdo, protože musí být pro každého zákazníka vyhrazený a tím se zvyšují náklady. |
||
| Lukáš66666 Profil |
#23 · Zasláno: 20. 4. 2016, 21:37:17
Davex:
A myslíš že by to mohlo být tím? Komplikace jsou dneska taky cca půl hodiny ale výkon zase nijak nenarostl. Nepomohl by třeba dedikovaný server? |
||
| Davex Profil |
#24 · Zasláno: 20. 4. 2016, 22:00:06
Lukáš66666:
Na základě známých informací se to nedá posoudit. S největší pravděpodobností bude příčina přetížení ve způsobu použití databáze v kombinaci s nevhodným nastavením systému a služeb. Vhodnou optimalizací by se to mohlo vyřešit, ale vyžaduje to hlubší analýzu, kterou tady neuděláme. |
||
| Lukáš66666 Profil |
#25 · Zasláno: 20. 4. 2016, 22:04:32
Davex:
Zkusím použít cache pro některé stránky webu třeba to pomůže. |
||
|
Časová prodleva: 9 let
|
|||
0