| Autor | Zpráva | ||
|---|---|---|---|
| Kocourek Profil * |
#1 · Zasláno: 21. 7. 2016, 14:38:12
Zdravím,
CRONem spouštím každou minutu cca. 2 PHP scripty, které tahají potřebná data z jiného webu. Jedná se o 5000-10000 položek, jejichž následné zpracování trvá příliš dlouho (Až do dalšího spuštění toho samého scriptu). Vkládám tedy tyto položky do dočasné tabulky v MySQL a každou minutu volám další script, který zjistí jestli jsou v tabulce nějaká data. V tabulce se nachází najednou klidně i 20000 záznamů, takže přes screen spouštím cca. dalších 40 scriptů, které položky zpracovávají po 500. Prvních pár hodin po spuštění funguje vše normálně, ale po pár hodinách už se ve spouštění scriptů začínají dělat i několikaminutové prodlevy a nakonec se apache zaseká úplně a nefunguje nic. Udělal jsem si i takový výpis kdy a jak dlouho běží který script ( ume.cz/vypis.html ). Každý pixel na stránce představuje 1 sekundu. Prosím tedy o radu zkušenější. Já už vážně nevím, jak tento problém řešit. Děkuji |
||
| nightfish Profil |
#2 · Zasláno: 21. 7. 2016, 15:01:34
1) Zkrátit dobu zpracování položek redukcí množství dat (třeba že by "jiný web" poskytoval data v podobě "změny za poslední minutu...", aby se nemusela pokaždé stahovat a zpracovávat komplet data).
2) Zkrátit dobu zpracování položek optimalizací skriptu (začal bych zjišťováním, které činnosti ve zpracování položek trvají nejdelší dobu). 3) Přesunout na server s vyšším výkonem. |
||
| Kocourek Profil * |
#3 · Zasláno: 21. 7. 2016, 15:07:47
Na serveru ze kterého tahám data nic měnit nemůžu a to samostatné zpracování právě nejvíce zdržuje to, že se 500x dotazuji zas úplně jiných serverů a nejdéle trvá, když server nefunguje, tzn. 1s timeout. Při sledování zátěže serveru jel celou dobu cca na 4%.
|
||
| TomášK Profil |
#4 · Zasláno: 21. 7. 2016, 15:11:09
Jakou roli v tom hraje apache? Spouštíš php skripty, které tahají data, dáš je do databáze, voláš další skripty, které zpracovávají data v databázi. Jediný apache, který v tom dává smysl je na serveru, odkud taháš data, ale tam přístup nemáš. Vychází mi z toho, že spouštíš ty php skripty přes apache. Spouštěj je přímo bez apache a vyhneš se problému s jeho limity.
Ale zvýšení výkonu od toho moc neočekávám. Určitě máš na serveru hardware na 40 paralelních výpočetních procesů? Pokud nečekají na disk, chtělo by to minimálně 16, lépe 32 procesorových jader. Pokud čekají na disk, zřejmě ho naplno vytíží i 10 procesů. |
||
| Kocourek Profil * |
Pravděpodobně tedy budu muset asi spouštět PHP scripty bez apache. Bohužel to pro mě, ale znamená duplikovat všechny funkce, které používám a upravit tak, aby fungovaly mimo můj CMS. Tomu jsem se chtěl právě vyvarovat.
Ještě mě napadlo. Je možné, že by to nezvládal screen? Používám ho vůbec správným způsobem? screen -A -m -d -S master_updater wget -qO- http://xxx > /dev/null |
||
| Davex Profil |
#6 · Zasláno: 21. 7. 2016, 22:08:05
Vypadá to, že tam máš logickou chybu. Mělo by se zamezit spuštění dalšího zpracování, pokud dřívější ještě neskončilo. Sám sebe Apache nezahltí.
|
||
| TomášK Profil |
#7 · Zasláno: 21. 7. 2016, 22:41:27
Davex
Já to chápu tak, že to není logická chyba, ale záměr. Dávkové zpracování zřejmě zvládne 500 položek naráz, aby to urychlil, tak pošle naráz 40 requestů, které zpracují 40x500 položek. Kocourek screen slouží k tomu, aby ses mohl odpojit od serveru? Jinak tam myslím taky nemusí být. Jestli je správně volený nedokážu bez dalšího kontextu říct. Myslím si, že apache není skutečný problém. Vypadá to, že se požadavky nestíhají vyřizovat, postupně se nahromadí a pak se přestanou vyřizovat. Tak dopadne jakýkoliv způsob, pokud nezrychlíš vyřizování požadavků nebo nezpomalíš frekvenci volání. Co znamená, že zátěž serveru je 4%? Procesor? A nestojí to na něčem jiném? Neswapuje ten systém? Nečeká na I/O disku?
|
||
| Kocourek Profil * |
#8 · Zasláno: 21. 7. 2016, 23:25:54
Během jedný sekundy spouštím třeba 40 těch screenů. Ano procesor jede stabilně na těch 4-10%. RAM 6/64GB. Disk netuším, ale to co se provádí by neměla být žádná velká námaha pro disk.
|
||
| TomášK Profil |
#9 · Zasláno: 22. 7. 2016, 00:37:02
Ten screen vypadá v pořádku, měl jsem dojem, že nebude vytvářet více stejnojmenných session, ale nemá s tím problém. Změní se něco, když to spustíš bez něj?
wget -qO- http://xxx & Každopádně pořád tipuju, že je problém je hromadění požadavků. A druhá divná věc, kterou bych zkoumal je, proč je server nevytížený, když by měl mít spoustu práce. Nemá to 16 jader? Pak by to mohlo být plné vytížení jednoho jádra a vyplatilo by se zkoumat, proč to běží jen na jednom. Jak apache spouští php? php-fpm, mod_fcgid? Není něco podezřelého v top?
Potřebuješ zjistit, kde to stojí. Pokud má server dost výkonu a je nevytížený, pak máš někde úzké hrdlo a je potřeba zjistit, kde to čeká. Buď se požadavky perou o nějaký zdroj (databáze, php procesy, disk) nebo na něco čekají (disk, síť). Přidal bych do toho výpočtu nějaké logování a zkoumal, co se děje. |
||
| Kocourek Profil * |
Zkoušel jsem tedy spouštět to bez screenu. Beze změny. Nastavil jsem také počet položek jen na 100 aby se nestávalo, že proces bude trvat déle jak minutu. Většinou teď trvá jen několik sekund, ale zase se spouští 200 scriptů najednou. Evidentně to vůbec ničemu nevadí, protože jsem 3 hodiny sledoval htop a žádné jádro procesoru nejelo naplno. Pak zas z ničeho nic konec.
Jak apache spouští php nevím. Jak to zjistím? |
||
| Davex Profil |
#11 · Zasláno: 23. 7. 2016, 22:32:12
Kocourek:
„Jak apache spouští php nevím. Jak to zjistím?“ Z výpisu phpinfo().
Jestli to chápu správně, tak zpracování trvá něco mezi 20 až 450 vteřinami, takže by bylo nejlepší dát do skriptu omezení, aby nikdy neběžel déle než třeba 50 vteřin a s nezpracovanými položkami by se pokračovalo při příštím spuštění. |
||
| Kocourek Profil * |
#12 · Zasláno: 24. 7. 2016, 10:49:41
Loaded Modules core mod_log_config mod_logio mod_version prefork http_core mod_so mod_alias mod_auth_basic mod_authn_file mod_authz_default mod_authz_groupfile mod_authz_host mod_authz_user mod_autoindex mod_cgi mod_dav mod_dav_fs mod_deflate mod_dir mod_env mod_include mod_info mod_mime mod_negotiation mod_php5 mod_proxy mod_python mod_reqtimeout mod_rewrite mod_ruby mod_setenvif mod_status mod_suexec Dobu zpracování jsem právěže už omezil, ale nemá to žádný vliv. |
||
| Davex Profil |
Kocourek:
„mod_php5“ PHP tedy běží jako modul Apache a počet současně běžících skriptů je omezen povoleným počtem Apache procesů. 1) Kolik jich v daný okamžik běží? Např. pokud používáš Debian/Ubuntu příkazem: pgrep -c apache2 .
2) Kolik je v Apache nastaveno MaxRequestWorkers (postaru MaxClients)?
|
||
| Kocourek Profil * |
#14 · Zasláno: 24. 7. 2016, 20:02:23
Davex:
1) Nejvíce jsem naměřil 168, ale může jich být i více. 2) MaxClients už jsem zkoušel přenastavovat. Nevím kolik tam bylo, ale dal jsem 1000 a beze změny. |
||
| Davex Profil |
#15 · Zasláno: 24. 7. 2016, 22:22:38
Kocourek:
ad 1) Pokud se každou minutu spouští 40 skriptů, které se ukončí do 60 vteřin, tak je 168 běžících procesů hodně (za předpokladu, že je nastaveno obvyklých MaxSpareServers 10 a neběží tam nic jiného).
Jak na serveru vypadá výpis z http://localhost/server-status/? Kolik je tam volných procesů a co dělají ty ostatní? Pokud tam bude víc jak 40 běžících skriptů spouštěných wgetem, tak to znamená, že běží déle než minutu.
ad 2) Pro větší hodnoty MaxClients než výchozích 250 se musí nastavit i ServerLimit. Nicméně se domnívám, že navyšování počtu procesů není správná cesta a vhodnější je skript zrychlit nebo rozdělit práci na menší části.
|
||
| TomášK Profil |
#16 · Zasláno: 25. 7. 2016, 01:36:53
Kocourek
Přidej logování. Zjistíš, co se jak dlouho provádí, na co to čeká. Dokud to nebudeš vědět, nech experimentů s apachem, je to střílení naslepo. Očekávám, že tam bude nějaká relativně malá část kódu, kde to bude trávit většinu času. Pokud tohle nepomůže, pak bych to přepsal na skript, který dokážeš spustit mimo apache. Nemělo by to být zas tak těžké, ať už ten kód vypadá jakkoliv. Stačí naplnit proměnné, které apache automaticky připraví ručně a spustit tu stránku, ne? Něco mi uniká? Každopádně pak můžeš mít pevný počet procesů, které začnou zpracovávat další dávku, jakmile dokončí tu současnou. Jak to vypadá, když se apache zaseká úplně a nefunguje nic? Pošleš požadavek na apache a on vytimeoutuje? Nebo dostaneš nějakých chybový status a v logu apache se něco objeví? Vzpamatuje se systém sám? |
||
|
Časová prodleva: 8 let
|
|||
0