ugrás a tartalomhoz

Symfony 2 - Twig - Out of memory

DarkHcK · 2016. Okt. 17. (H), 09.15
Sziasztok!

Szeretnék ötletet/tanácsot kérni egy hiba elhárításában, hátha belefutott már valaki. Van két Symfony 2 -es projektem, s már nem először fordult elő az alábbi hibaüzenet:

[17-Oct-2016 07:59:16 Europe/Berlin] PHP Fatal error: Out of memory (allocated 8388608) (tried to allocate 163840 bytes) in E:\xampp\htdocs\khronos\app\cache\prod\twig\40\4001ede42ae18acec62f90c71b181538a1960d3d452ef89373897519935f63e0.php on line 533


Ez a hibaüzenet ismétlődik nagyon sokszor.

Symfony 2.4 illetve 2.8 -as verziók futnak. A xampp -ban jelenleg 7 -es php van, 2GB a memory_limit a php.ini -ben.

Próbáltam már dev környezetben reprodukálni a hibát, de nem sikerült.
Valakinek akad valami ötlete, hogy mitől akadhat így ki?

Előre is köszi a válaszokat ;)
 
1

Ciklus

Hidvégi Gábor · 2016. Okt. 17. (H), 09.28
Nézd meg azt a fájlt, aminek a neve az üzenetben van, lehet, hogy egy végtelen ciklus okozza. Sajnos az ilyen hibák okának kiderítése elég macerás.

Ezzel a magas memórialimittel vigyáznék, mert pár párhuzamos lekéréssel padlóra lehet küldeni a szervereteket. Már 128 és 256 megabájt is nagyon sok egy script számára, utána kéne járni, hogy miért megy e fölé a programotok.
5

Memory Limit levéve

DarkHcK · 2016. Okt. 17. (H), 10.24
A memory_limit -et levettem 1024MB -ra. Köszi, hogy felhívtad rá a figyelmem :)
A másik, hogy véleményem szerint nincs végtelen ciklus. Minden felület ki van tesztelve többszörösen. A dev és prod környezet ugyan az, s mégis csak a prod környezetben jön elő a hiba.
7

A dev és prod környezet ugyan

Hidvégi Gábor · 2016. Okt. 17. (H), 14.24
A dev és prod környezet ugyan az, s mégis csak a prod környezetben jön elő a hiba
Akkor biztosan nem ugyanaz a két környezet.
10

RE: A dev és prod környezet ugyan

DarkHcK · 2016. Okt. 17. (H), 15.27
Jó...az OS más alatta, de ugyan az a XAMPP, s ugyan olyan cofig beállításokkal futnak a környezetek.
2

http://stackoverflow.com/ques

Poetro · 2016. Okt. 17. (H), 09.31
http://stackoverflow.com/questions/12015569/fatal-error-out-of-memory-but-i-do-have-plenty-of-memory-php#12178235
6

Próba

DarkHcK · 2016. Okt. 17. (H), 10.26
Most beállítottam egy MaxRequestsPerChild 100 -as értéket. Meglátjuk... hátha megoldódik a probléma ;)
3

8MB

vrnagy · 2016. Okt. 17. (H), 09.35
Ha megnezed a hibauzenetet, akkor azt irja, hogy 8388608 bajtnyi memoriat foglalt le eddig (8MB), es szuksege lenne meg 160KB-ra.

A phpinfo()-bol keresd elo a memory_limit erteket, mert szerintem az alap 8MB-ra van allitva.
4

phpinfo

DarkHcK · 2016. Okt. 17. (H), 10.21
A phpinfo() szerint a memory_limit 2048MB.
8

Félig kapcsolódik

Hidvégi Gábor · 2016. Okt. 17. (H), 14.41
Kíváncsi vagyok, meddig fog az alkalmazásotok működni. Számomra két jele van annak, hogy alaposan mellényúltatok:

1, a program elérési útvonalában a cache szócska

Ha szerveren belül szükség van cache-re, az rég rossz, hisz legalább egy komponens olyan lassú/bonyolult, hogy csak így lehet elfogadható sebességet kihozni belőle. Idővel a helyzet csak rosszabb lesz, hisz az esetek 99%-ában úgyis csak több és több featúra lesz beépítve.

2, a magas memórialimit

A PHP rendkívül pazarlóan bánik a memóriával; ha nagy mennyiségű adatot kell feldolgozni, egy statikus típusos programozási nyelvben a mostani egy gigabájtos limit töredékéből ki lehetne jönni, ráadásul ennyivel gyorsabban. Erre tudnám ajánlani például a Go-t.
9

Re: Félig kapcsolódik

DarkHcK · 2016. Okt. 17. (H), 15.25
Jelenleg már 2 éve megy az alkalmazás. :)
A cache -ről annyit, hogy ez alapértelmezetten van a symfony2/twig -ben.

Abban teljesen egyet értünk, hogy pazarlóan bánik a memóriával, s köszönöm az ajánlást, de a szervezeti infrastruktúra miatt az asp.net/c# opción gondolkodom.

Most kíváncsian várom, hogy 2-3 nap alatt ismét előfordul -e a hiba, vagy sem. Reménykedem az utóbbiban. :)
11

Ha szerveren belül szükség

BlaZe · 2016. Okt. 17. (H), 22.37
Ha szerveren belül szükség van cache-re, az rég rossz, hisz legalább egy komponens olyan lassú/bonyolult, hogy csak így lehet elfogadható sebességet kihozni belőle.
Ezt miért gondolod, hogy így van? Ami adat egyszer előállt, azt miért kéne újból előállítani, ha megoldható a hozzáférése hatékonyabban is?
12

htdocs\khronos\app\cache\prod

Hidvégi Gábor · 2016. Okt. 19. (Sze), 13.08
htdocs\khronos\app\cache\prod\

Ha megnézzük ezt a karakterláncot, látszik belőle, hogy a kas szerves részét képezi az alkalmazásnak, a produkciós kód teljes egészében benne van, abból szolgálják ki. Magyarul a keretrendszer alapból annyira lassú/erőforrásigényes, hogy csak gyorstáron keresztül használható. Még egy sort sem írtam, az üzleti logikából nem valósítottam meg semmit, de már cache-elünk. Ez nonsense.

Ha ennyire bonyolult a keretrendszer, rég rossz. Egyrészt hiba esetén várható, hogy sok idő lesz a javítása, tesztelése. Másrészt valószínű, hogy sok hiba van benne, hisz ami elromolhat, el is romlik, és nem csak az egyes komponensek lehetnek rosszak, hanem a köztük lévő kapcsolatok is növelik a problémák esélyét.
13

PROD

Poetro · 2016. Okt. 19. (Sze), 14.18
Éles környezet esetén mindenképpen érdemes cachelni, akár lassú a keretrendszer (ami PHP esetén elég valószínű), akár gyors. Mivel ekkor a magának a keretrendszer egészének nem kell felépülnie, máris kiszolgálható a tartalom, amennyiben elérhető. Így kihagyható az adatbázis, további külső szolgáltatókhoz való hozzáférés stb. Azaz az egész rendszered jobban skálázódik, főleg nagyobb látogatottság esetén.
14

Opcache

Hidvégi Gábor · 2016. Okt. 20. (Cs), 08.01
Erre ott van a PHP beépített Opcache-e, egyéb adatokat pedig lehet a munkamenetben tárolni. Az adatbáziskapcsolatok más tészta, nem tudom, érdemes-e és hogy mikortól perzisztensen kezelni őket.
15

Hm, akkor most a http session

BlaZe · 2016. Okt. 20. (Cs), 22.13
Hm, akkor most a http session nem egy cache? Elég rossz tapasztalatod lehet, ha irtózol a cache-ektől. Az egyik legkézenfekvőbb és leghatékonyabb teljesítménynövelő megoldás, ami csak létezik. Ráadásul amíg nem distributed egy cache, addig még csak nem is különösebben nagy extra komplexitás. Distributed környezetben meg amúgy is megvannak az abból adódó problémák...