Allowed memory size exhausted in ComponentContainer
- redhead
- Člen | 1313
Nějakou dobu jsme jeli bez nejmenšího problému na PHP 5.2 s Nette verzí 0.9.x a po přesunu na server s PHP 5.3 se nám u některých stránek objevuje:
Fatal error: Allowed memory size of 41943040 bytes exhausted (tried to allocate 261900 bytes) in /var/www/clients/client3/web3/web/libs/Nette/ComponentContainer.php on line 94
(nebo taky lajna 191)
Navýšení paměti jsme už zkoušeli, navíc se nejedná o nijak náročné stránky, spíše naopak – stránka, kde se generuje PDF přes mPDF (u které jsme museli původně na 5.2 navýšit paměť), jede nyní bez problémů.
Zajímavé také je, že se to vždy objeví u ComponentContainer.
Díky za rady.
- Ot@s
- Backer | 476
redhead napsal(a):
Nikdy jiný se s tím nesetkal? Ani nevíte v čem by mohl být zádrhel?
Kolik rezervovane pameti (memory limit) ukazuje phpinfo na produkci a lokale? Zkusil bych na produkčním serveru udělat jednoduchý skript, který by alokoval skoro maximální hodnotu povolené ram a cvičně reloadoval. Pokud by občas vyskakovaly tytéž fataly, tak je možné, že se jedná o nekvalitní hosting, co hostuje na webserveru s 2GB ram (nebo hostuje přemíru projektů).
- arron
- Člen | 464
Prijde mi na tom zvlastni, kolik pameti se snazi alokovat. Tyhle chyby vzdycky padaji, kdyz se snazim alokovat vic nez je limit, ale zpravidla se snazi alokovat pár bytů, které jsou potřeba k uložení nějakého dílčího výsledku (či čehosi). Tady se snaží alokovat poměrně velkou část paměti najednou, což je divné…zkus se zamyslet, co přesně se v té aplikaci může snažit alokovat takové množství paměti najednou.
- redhead
- Člen | 1313
Právě, že mě nic nenapadá. Nejde o kdovíjak náročné stránky a na předešlém PHP 5.2 to šlo v pořádku. Paměť jsme tam museli navýšit jen kvůli mPDF, který si skutečně bere dost, jinak jsou to prakticky výpisy s db, které jsou samozřejmě stránkované (a na localhostu i na 5.2 to šlo i s od dost menším limitem paměti, než je nastaven teď).
- Fandik
- Člen | 19
@Ot@s:
Na localhostu mám 128MB a na hostingu je 48MB. Zkusil jsem tento skript:
echo memory_get_usage() / (1024*1024) . ' MB<br>';
$a = str_repeat('abcdefghij',4.9e6);
echo memory_get_usage() / (1024*1024) . ' MB<br>';
$a = NULL;
echo memory_get_usage() / (1024*1024) . ' MB<br>';a výsledky?
hosting to v pohodě zvládá i po několikerým obnovení stránky. Jinak
tady ještě konkrétní čísla:
| localhost |
|---|
| 0.31745147705078 MB |
| 47.047584533691 MB |
| 0.31752777099609 MB |
| hosting |
|---|
| 0.60427093505859 MB |
| 47.33447265625 MB |
| 0.60440826416016 MB |
- Vyki
- Člen | 388
Řešil jsem podobný problém před měsícem. Chybová hláška
Fatal error: Allowed memory... byla stejná a bylo to kvůli
robotLoaderu. Ve složce libs, kterou indexuji jsem totiž vedle Nette a NotORM
měl i soubory s knihovnou HTMLPurifier, která nepatří k nejmenším.
Když jsem indexování této složky pomocí direktivy v souboru
netterobots.txt zakázal a zařídil načítání ručně, začalo vše
fungovat. Pokud si vzpomínám mPDF také není zrovna nejmenší balík.
Editoval Vyki (13. 10. 2011 17:46)
- David Grudl
- Nette Core | 8228
RobotLoader používá funkci token_get_all, která si umí ukousnout pěkný
kus paměti. Třeba pro soubor nette.min.php chce 55 MB! Řeší
se to tak, že se na první řádek souboru přidá:
<?php //netteloader=trida,tridase seznamem tříd definovaných v souboru a on je použije místo analýzy. Druhá možnost by byla nahradit tokenizer za méně spolehlivé hledání tříd podle nějakého regulárního výrazu.