PHP a Nette v nekonečném cyklu na serveru

Moc zkusenosti s tim nemam, jen takove prakticke veci co jsem zjistil, kdyz jsem neco testoval s hodne dlouhymi scripty. Ikdyz jsem na serveru nastavil cas vykonavani scriptu na dlouho dobu, tak mi aplikace padala po nake dobe kvuli nedostatku pameti. Nevim jestli se to da nak poresit, ale ikdyz jsem to zkousel zmenit, tak to stejne po case padlo jejim vycerpanim.

@pawouk: démona v čistém PHP provozuji a nebyl problém s během v řádu týdnů (workery se z hlavního procesu forkovaly a posléze ukončovaly, takže na problém s memory leaks jsem nenarazil)

démona na Nette jsem nezkoušel

No tak to jsou dobré zprávy. Tak já to asi zkusím a napíšu zkušenosti. Díky

Jde to i v php a s nette. Jen se musí dodržovat pár zásad. Testováno na skriptu, který parsuje tisíce XML souborů o velikosti až jednotek MB které průběžně získává přes curl z externí služby a volá tisíce sql dotazů. Kromě paměti, kterou potřebuje na data si php i během několika hodin nevezme navíc jediný byte. Ale je to celkem sranda odladit, když člověk nemá zkušenosti. (skript vlastně běžel skoro dva dny a více než 200 000 poměrně náročných cyklů, než spadl, když jsem mu pod rukama nedopatřením změnil struktůru databáze)

Hlavní tip: paradoxně – vůbec se nestarat se o uvolňování paměti a nechat to na php. Ale zároveň nebránit uvolňování paměti špatnými konstrukcemi a nezabírat paměť zbytečnými proměnnými. Jinak je to téma na celý článek.

Nette samotné je napsáno dobře a paměť nežere.

Editoval LeonardoCA (13. 12. 2012 3:05)

Souhlas, spíš bych řekl, že to neustálé spouštění je právě naopak v PHP problém, i pokud zapojíme různé akcelerátory, stejně ta inicializace bude pomalejší než v ostatních jazycích, vše se zahodí a zase startuje znovu (což je i výhoda, ale tady zrovna moc ne).

Taky mám s dlouhoběžícím Nette dobré zkušenosti, zatím teda ne v řádu dní, ale hodin.

Samozřejmě je hlavní vše zpracovávat průběžně a nepoužívat konstrukce typu „načtu vše a pak to projdu“. A bacha jestli neprobíhá nějaké logování nebo cachování v paměti bez toho, aby si kontrolovalo velikost.
Jestli je problém s manuálním uvolňováním nevim, radši vše (v takových skriptech) ruším hned jak vím, že to není potřeba, než až PHP zjistí, že už to není potřeba.

@pawouk: V PHP píšu daemony dost často a nemám problém. Pokud budeš chtít forkovat a spravovat víc potomků (desítky) tak tam už je to náročnější, ale dá se. Ikdyž Nette jsem v daemonu nikdy nepoužil.

napisal som daemony ktore bezia mesiace v kuse, nacitavaju spravy z rabbit mq a spracuvaju ich. pouzivaju sluzby z nette. skript daemona si nacita bootstrap php a ma vsetko k dispoizicii. o loopovanie sa stara rabbit mq kniznica, ale normalny while by fungoval tiez.

ako db sa pouziva mongo db cez doctrine odm. spojenie s db nepadlo ani raz, specialne som nenastavoval nic, ale predpokladam, ze pri spracovani kazdeho messagu sa vytvorilo nove spojenie.

forkovanie podprocesov som v daemonoch nepouzil, iba v cronoch, ale celkom spokojny som bol s power process kniznicou. inak na githube su mraky kniznic na daemonizovanie a forkovanie procesov.

na monitoring a manazment tych daemonov som pouzival supervisord, super vecicka, spusti hociaky php skript ako daemon.

co sa tyka pamate tak vsetky premenne po pouziti setnem na null a este zavolam gc collector. setovanie na null dost setri pamat, pri gc collect som nejaky extra rozdiel nespozoroval

Co se týče gc collect, tak jsem zkoušel asi den, dva různé experimenty a nikdy se to nechovalo podle očekávání. PHP si paměť stejně uvolňuje až když se mu chce (zjednodušeně). Našel jsem i zajimavé zdroje, jak PHP mapuje proměnné a reference interně, ale to je tak na týden, 14 dní studia, aby to člověk pochopil, vyzkoušel a dospěl k nějakému použitelnému závěru.

Dával jsem gc_collect na různé místa, ale nikdy se mi nepodařilo uvolnit paměť, když jsem chtěl já.

• řekl bych že pomáhá mít dobře rozčleněný kód do bloků, protože PHP samo automaticky uvolňuje paměť právě ve chvíli kdy ukončí práci v nějakém bloku.
• proměnné většinou ani nenastavuji na null, protože je používám opakovaně a tak se přepisuje už jen paměť, kterou mají rezervovanou, a je to možná i efektivnějšší a hlavně jsem se snažil nepoužívat skoro žádné dočasné proměnné
• místo cyklů foreach, atp, se vyplatí používat funkce array_map, array_filter a podobné, případně iterátory

Editoval LeonardoCA (13. 12. 2012 15:54)

@Nox můžeš hodit odkaz na to kde se řešilo array vs foreach? Moc mi to nesedí, možná ty funkce používám jiným způsobem. Až bude čas, zkusím porovnat…

Co mě trklo, tak v komentářích odkazují na nějaký test s číselnými poli a triviální operací a to má do praxe dost daleko. Myslím si že při komplexnějších operacích nad víceúrovňovými associativními poli se projeví úplně jiné faktory a výsledek bude vypadat jinak. Koncem roku zkusím udělat nějaké testy na reálných datech a hodím to sem.

Jedna věc je, že php díky interní datové struktůře při práci s poli zabírá nehorázně více paměti než je skutečná velikost dat a je jasný, že foreach iterátor nezabere nic navíc. Druhá věc je, že při použití array funkcí si php samo efektivně paměť pohlídá a ve foreach si to musíš víc hlídat sám. Při komplexnějších úlohách pochybuju, že bude foreach vždy efektivnější, minimálně se rozdíly smažou.

Tohle jsou jen dohady, fakta jsou zde. Udělej ten benchmark a pak uvidíme:)

Nezkoušel jsem to, ale asi bych udělal nějaký testovací „select“ dotaz, zachytil na něm tu výjimku a v připadě „gone away“ vytvořil novou connection.

(Kdyby měl být skript brutálně robustní, tak by měl být schopen vychytat i stavy, kdy db server neodpoví třeba kvůli přetížení, když běží zálohy a pak by to chtělo zachytávat výjimky nad celým skriptem a po nějakém čase zopakovat předchozí neúspěšný cyklus. To samé se mi stává u externí služby, že má občas pár minut výpadek. Ale to záleží na tom co se zpracovává, je li to třeba řešit)

Editoval LeonardoCA (20. 12. 2012 17:44)

@pawouk: Ten pokládaný dotaz by mohl být něco jednoduššího, například začátek transakce, což bys o chvilku později zpravidla volal tak jako tak.

EDIT: Nebo „SELECT 1“.

Editoval enumag (22. 12. 2012 9:57)