Drupal túllépi a 128 MB-os (!) memóriakorlátot

Sk8erPeter képe

Sziasztok!

Éles szerveren a Drupal jópár contrib modullal túllépi a 128 MB-os (!!) memóriakorlátot. Ez nagyon durva, ezért gyanakodtam arra, hogy valamelyik contrib modul nagyon durván leak-el.

Localhostra pontosan ugyanezt a Drupalt feltettem, majd felraktam az XHProf extensiont, amit a Devel modul javasol, aztán beállítottam a megfelelő path-t ennek az extensionnek, és mindenféle query-t logoltatok a Devellel, hogy mindezt figyelni tudjam.
Ki is íratom az eredményeket az említett XHProffal, és pl. az egyik oldallekérésre ezt írja:

Total Incl. PeakMemUse (bytes):        16,114,824 bytes

Ezzel a 16 MB-os nagyságrendű erőforrásigénnyel még semmi bajom nem lenne, de hogyan lehetséges, hogy ugyanekkor az éles szerveren már egy nyamvadt content type létrehozásakor is (!) túllépi a 128 MB-ot? Ugyanezek között a körülmények között méregetem localhoston, és semmi ilyen jellegű bajom nincs.

Van tippetek?
Ti mivel szoktátok mérni a PHP memóriazabálását?

Előre is köszi bármiféle ötletet!

U.i.:
Gyanakodtam már az igen erősen használt Display Suite-ra ÉS Field group modulra is, hátha ez a kettő ilyen mértékben elszáll memóriaigénnyel... De lehet, hogy totál máshol kell keresni a hibát...

Melyik modulhoz, modulokhoz kapcsolódik a téma?: 
Drupal verzió: 
szantog képe

Ezen nem kell meglepődni. Cron futás, vagy full cache rebuild simán megehet 150-160M memóriát. CT létrehozása, meg field mentése tipikusan olyan, amikor törlődik a cache. És igen, display suite, panels, field group, mindegyikben van anyag bőven.

És nem egy modul lépi túl a memóriát, hanem a modulok munkájának összessége.

Sok mindent nem lehet vele csinálni, leginkább drusht érdemes használni, mert ugyan semmilyen hmtlel kapcsolatos kess nem jön létre, mégis full bootstrapped, szóval pár dög registryt létrehoz ő is, illetve ilyen óriási oldalakon szoktam cachet üríteni, mint pl a admin/modules/uninstall, ha esetleg drushtalanság lenne.

2
0

----
Rájöttem, miért kérdezek olyan ritkán a drupal.hu-n. Amíg szedem össze az infokat a kérdéshez, mindig rájövök a megoldásra.

Sk8erPeter képe

Köszönöm a választ!
De továbbra sem világos számomra, hogy localhoston a mérések szerint hogyan lehetséges, hogy mégis jóval kevesebbet mutat az XHProf, meg a Devel modul is, ami az oldal összerakásának legvégén kiírja, hogy mennyi volt a peak memory usage?

Amúgy elfelejtettem mondani, hogy localhoston 5.3.8 van fent (ahol nincs para), a szerveren pedig 5.2.17-es verzió. Már ha ez számíthat.

Szerk.:
közben itt kaptam egy választ, ami lehet, hogy igazából megválaszolja a kérdést:
http://prohardver.hu/tema/php_kerdesek_2/hsz_11415-11415.html
Jó gondolatmenetnek tűnik.

1
0
Illyés Edit képe

A szerveren a phpinfo fájl mit mutat? (/admin/reports/status/php oldal). Van fent valamilyen op-code cache, pl. APC?

0
0
Sk8erPeter képe

Szia!

"Természetesen" a szolgáltató volt oly kedves, hogy ennek a függvénynek a használatát letiltotta. Sok szolgáltatónál sajnos abba a téves elképzelésbe ringatják magukat, hogy ez hű de nagy védelmet jelent.

Az a durva, hogy a szerveren az admin/reports/status oldalt sem tudom megnézni, mert kapok egy ilyen exceptiont, ami valószínűleg összefüggésben van ezzel is.
Egyre kevésbé tetszik ez a szerver, ahol most tárolódik a cuccunk.
Ha lehet detektálni másképp is, akkor megpróbálom!

1
0
aboros képe

irány másik szolgáltató. egyszerűen ennek a kérdésnek az eddigi infók alapján ez a meogldása.

2
0

-
clear: both;

Sk8erPeter képe

Köszi, úgy tűnik, valóban ez a megoldás marad, főleg, hogy eléggé hajthatatlannak tűnik a szolgáltató. Pedig eleinte az szimpatikus volt a részükről, hogy kértem, hogy növeljék már meg a 64 MB-os korlátot 128 MB-ra, és pár órán belül meg is tették a kérésnek megfelelően.

De ilyen fura hibákat eddig egyetlen szolgáltatónál sem tapasztaltam, még meghízott Drupal esetén sem, és a 128 MB-ot még eddig sosem sikerült átlépni.
Most már csak a megrendelőt kéne meggyőznöm a szolgáltatóváltásról, aki nagyon nem fogja érteni, hogy ugyan mi a baj ezzel a mostanival...

0
0