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...
Ezen nem kell meglepődni.
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.
----
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.
Köszönöm! De localhoston miért kevesebb mégis a mérések szerint?
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.
op-code cache?
A szerveren a phpinfo fájl mit mutat? (/admin/reports/status/php oldal). Van fent valamilyen op-code cache, pl. APC?
Nem tudom megnézni
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/statusoldalt 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!
akkor léc
irány másik szolgáltató. egyszerűen ennek a kérdésnek az eddigi infók alapján ez a meogldása.
-
clear: both;
Köszi, úgy tűnik, valóban ez
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...