Fatal error: Allowed memory size of 33554432 bytes exhausted

faglork · 02. April 2013 16:33

Klenkes schrieb:

Klenkes schrieb:
Ich betreue auch eine Website mit ca. 500 Seiten im Katalogstil in 4 Ebenen tief, und die Seite läuft stinknormal unter Shared Hosting mit max_exec 10s, und mit, ich glaube, 32MB Speicher.
Klar, alles nicht unter 1 Sekunde, aber annehmbar.
Muss mich selbst nochmal korrigieren.
Es stehen 64MB Speicher zur Verfügung.
Von den momentan über 600 Seiten sind praktisch alle als Contentpage(Cataloger) angelegt, was das Backend zwar unübersichtlich macht, aber immer noch "händelbar"
Memoryfehler hatten wir bis jetzt noch nicht.

Dito hier. 30s, 64M, ca 600 Seiten.

Das größte Problem bei sowas ist das Anlegen neuer Seiten. Das Auswählen der übergeordneten Seite aus einer Liste mit 600 Einträgen ist einfach besch... wenn es wenigstens so gelöst wäre wie bei der "Internen Seitenverlinkung" im TinyMCE (so zum Ausklappen). Und wenns dann noch mehrsprachig ist und man die Bäume synchron aufbauen muss ... igitt.

Servus,
Alex

mike-r · 11. April 2013 12:53

mike-r schrieb:

Der Hoster der Wahl bietet seit neuestem für 6€/p.a. zusätzliche 32MB Ram an, das ist erst mal ein Weg, den ich gehen werde, am eigentlichen Problem selbst ändert das nichts, wer sagt mir, dass ich in 2 Jahren nicht weitere 32MB brauche ...

So. sad
Ich hab jetzt 72MB. Läuft alles, bis auf das wichtigste: Seiten bearbeiten:

Fatal error: Allowed memory size of 75497472 bytes exhausted (tried to allocate 122880 bytes) in /home/www/.../html/lib/smarty/sysplugins/smarty_internal_compile_foreach.php on line 128

Interessanterweise läuft es, wenn ich das Menü im Template deaktiviere. Den Seitenbaum sehe ich beim Bearbeiten trotzdem.
Nanu?
Menüaufruf:

Hier klicken, um den Code zum Kopieren zu markieren

{menu template='simple_navigation.tpl' collapse='1'}

Die Menüverwaltung kann ich nicht öffnen:

Hier klicken, um den Code zum Kopieren zu markieren

 Fatal error: Call to a member function MoveNext() on a non-object in /home/www/.../html/lib/classes/module_support/modtemplates.inc.php on line 47

da hab ich ja erst mal einen Ansatz wo weiterzusuchen ist.
Oder jemand auf die Schnelle ne Idee, wie ich das korrigiere?

NaN · 11. April 2013 13:42

Wenn die Anzeige im Backend unter "Inhalte->Seiten" davon abhängig ist, ob das Menü im Frontend-Template steht oder nicht, dann bedeutet das, dass das Template geparst/verarbeitet wird, während der Seitenbaum erstellt wird. Und das bedeutet ... nutzt Du AdvancedContent? Wenn ja, welche CMS/AC Version und nutzt Du die erweiterten Einstellungen des Moduls? (der Tab "erweiterte Einstellungen" beim Bearbeiten von Seiten, wo man z.B. Start/End-Datum angeben kann)

mike-r · 11. April 2013 15:50

Nein, es werden ausschliesslich Inhaltsseiten genutzt.

Module habe ich gerade komplett bis auf Menümanager deaktiviert -> keine Änderung.

Edit: Inhalte-> Seiten funktioniert (solange ich sie nicht komplett aufklappe), das bearbeiten der Seiten schlägt dann aber mit obiger Meldung fehl.
Edit² CMS und Module sind alle die aktuellste Version.

Edit³: das Menumanager-problem kommt scheinbar nicht mehr aus dem Seitenbaum, ich habe gerade lokal grosszügig rumgelöscht, und es besteht weiterhin.

Beitrag geändert von mike-r (11. April 2013 16:31)

NaN · 11. April 2013 16:42

Edit: Inhalte-> Seiten funktioniert (solange ich sie nicht komplett aufklappe), das bearbeiten der Seiten schlägt dann aber mit obiger Meldung fehl.

Ist ja auch logisch. Und ein alter Hut.
Zu viele anzuzeigende Seiten -> Memory-Problem.
Zusammenklappen aller Seiten -> Lösung für die Inhaltsübersicht.
Beim Bearbeiten einer Seite werden aber wieder alle Seiten für das Dropdown "Übergeordnete Seite" geladen -> Wieder Memory-Problem roll

Das MenüManager-Problem kann ich gerade nicht nachvollziehen (bin unterwegs).
Klingt aber nach einem Programmierfehler bzw. danach, dass nicht geprüft wird, ob eine bestimmte Aktion erfolgreich war, bevor man fortfährt. Die Frage ist, warum diese Aktion nicht das gewünschte Objekt liefert, um die Funktion MoveNext() ausführen zu können.

Klenkes · 11. April 2013 17:11

mike-r schrieb:

Nein, es werden ausschliesslich Inhaltsseiten genutzt.
Edit: Inhalte-> Seiten funktioniert (solange ich sie nicht komplett aufklappe), das bearbeiten der Seiten schlägt dann aber mit obiger Meldung fehl.

Ich kann nur einen Eigencheck anbieten.
620 Inhaltsseiten, davon 610 untehalb 1 Toplevelmenüpunktes.
Das Aufklappen aller Punkte klappt bei mir mit 64MB problemlos.

Ich denke auch, dass der Fehler eher woanders liegt, als an der schieren Menge der Seiten.

Andynium · 11. April 2013 20:36

mike-r schrieb:

(u.a. auf der myaccount.php, wozu will die den Seitenbaum ziehen?)

Eher anders herum, der Zustand des Seitenbaums wird benutzerspezifisch gespeichert.

mike-r schrieb:

Jetzt ist die grosse Quizfrage, ob ich auf Verdacht die Struktur von gefühlt auch 500 Seiten komplett rumschieben muss, oder ob es eine andere Lösung für 48MB gibt?

Tritt/trat dies auch mit einem neuen Benutzer auf?

mike-r · 12. April 2013 23:31

NaN schrieb:

Klingt aber nach einem Programmierfehler bzw. danach, dass nicht geprüft wird, ob eine bestimmte Aktion erfolgreich war, bevor man fortfährt.

Dafür spricht, dass ich eine ähnliche Fehlermeldung im Netz gefunden habe zu irgendeinem Joomla-Plugin, wo ein "if !empty" oder dergleichen fehlte (Bin kein Programmierer und den Link habe ich um die Uhrzeit auch nicht mehr parat wink )

Klenkes schrieb:

Ich kann nur einen Eigencheck anbieten.
620 Inhaltsseiten, davon 610 untehalb 1 Toplevelmenüpunktes.

Danke, hilft mir leider nicht, da bei mir alles bunt zerwürfelt ist.
Btw: Wie zählst Du die Seiten?

Ich denke auch, dass der Fehler eher woanders liegt, als an der schieren Menge der Seiten.

Ja denke ich auch. Ich befürchte ich habe bei Ex- und Import etwas falsch gemacht - oder im schlimmsten Falle ist die Original-DB schon "kaputt" und ältere CMSe haben das noch toleriert.

@cyberman das Problem tritt auch mit einem _anderen_ Benutzer auf. Einen _neuen_ teste ich morgen (also heute).

Danke an alle für die Unterstützung bisher.

Beitrag geändert von mike-r (12. April 2013 23:34)

Andynium · 12. April 2013 08:34

cyberman schrieb:

Das Problem hatten wir vor langer Zeit in einem der Foren (weiß nur nicht mehr, in welchem ) und da gabs auch eine Lösung. Kann den Thread aber gerade nicht mehr finden.
Aber irgend wie war mir, als ob damals eine Änderung in der DB Abhilfe geschaffen hätte, indem das Feld, wo der (geöffnete) Seitenbaum gespeichert wird, von TEXT auf auf MEDIUM TEXT geändert wurde ...

OK, habs gefunden und hier publiziert.

Aber du hast das Problem ja zwischenzeitlich durch die Speichererhöhung anderweitig gelöst ...

mike-r · 15. April 2013 21:25

Noch jemand ne Idee, wie ich das menumanager/ movenext-problem lösen kann?
Gerade mal eine ältere Menumanager-version probiert, bekomme ich keine Fehlermeldung, allerdings auch nur die Tabs angezeigt (soweit komme ich mit der 1.8.5 nicht)
Ich habe leider keine Version zwischen 1.4 und 1.8.5, die 1.7.x hat nicht zufällig wer rumliegen und kann sie mir geben? Im Forge ist sie nicht.

Beitrag geändert von mike-r (15. April 2013 21:42)

NaN · 16. April 2013 07:40

Ich habe leider keine Version zwischen 1.4 und 1.8.5, die 1.7.x hat nicht zufällig wer rumliegen und kann sie mir geben? Im Forge ist sie nicht.

Doch: http://dev.cmsmadesimple.org/project/fi … lease-2467 wink

Andynium · 16. April 2013 08:23

Ich vermute mal, dass die MM-Version gemeint war roll ...

Cherry · 16. April 2013 10:02

mike-r schrieb:

Ich habe leider keine Version zwischen 1.4 und 1.8.5, die 1.7.x hat nicht zufällig wer rumliegen und kann sie mir geben? Im Forge ist sie nicht.

MM1.7.7 war in CMSms 1.10.1 mitgeliefert. Das müßstest doch von dort nehmen können.

mike-r · 16. April 2013 20:08

Danke, hab jetzt ein paar durchprobiert -> keine Änderung.

Ich werde jetzt nochmal von vorne anfangen und zusehen, ob ich das Schritt für Schritt updaten kann, bis ich den Fehler hoffentlich finde.

czarnowski · 16. April 2013 21:05

Ich würde es ,al mit der geänderten Funktion versuchen (in modtemplates.inc.php)

Hier klicken, um den Code zum Kopieren zu markieren

[== PHP ==]
function cms_module_ListTemplates(&$modinstance, $modulename = '')
{
	$gCms = cmsms();

	$db = $gCms->GetDb();
	$config = $gCms->GetConfig();

	$retresult = array();

	$query = 'SELECT * from '.cms_db_prefix().'module_templates WHERE module_name = ? ORDER BY template_name ASC';
	$result =& $db->Execute($query, array($modulename != ''?$modulename:$modinstance->GetName()));

	while (!empty($result) && is_object($result) && !$result->EOF)
	{
		$retresult[] = $result->fields['template_name'];
		$result->MoveNext();
	}

	return $retresult;
}

mike-r · 16. April 2013 21:58

Bingo, danke, bringt mich einen Schritt weiter, der Menümanager läuft.

Bzw. ... leider auch wieder 2 Schritte zurück, ich bin endlich wieder im Topic glasses
Meine 72MB Ram reichen immer noch nicht und ich bin wieder am Anfang. Komischerweise lief das Seiten bearbeiten auf meinem (mittlerweile verfrickelten) 64MB-Testsystem. es ist zum Verzweifeln.

Edit: gibt es denn nicht irgendeine Möglichkeit, das rendern von {menu} im Backend abzustellen? Ich verstehe das nicht, dass der Seitenbaum trotzdem da ist ... wozu brauche ich das dann da?

Beitrag geändert von mike-r (17. April 2013 22:04)

Andynium · 17. April 2013 05:15

cyberman schrieb:

cyberman schrieb:
Aber irgend wie war mir, als ob damals eine Änderung in der DB Abhilfe geschaffen hätte, indem das Feld, wo der (geöffnete) Seitenbaum gespeichert wird, von TEXT auf auf MEDIUM TEXT geändert wurde ...
OK, habs gefunden und hier publiziert.

Hattest du dies gecheckt?

czarnowski · 17. April 2013 11:39

Wenn die für den Aufbau einer Navigation notwendigen Informationen pro Seite im Schnitt deutlich weniger als 100 Bytes pro Seite kann man sich sehr gut vorstellen das selbst wenn man 8MB als Grundbedarf abzieht ein Bedarf über 64 MB oder gar über 70 MB für 500 Seiten extrem überzogen ist .

Die Ursachen sind aus meiner Sicht vielfältig

a. das Menüsystem ist völlig unwirtschaftlich aufgebaut
b. die Konsistenz der Daten ist nicht gesichert

Das aber habe ich bereits vor vielen Jahren geäussert und auch an Beispielen belegt wie man es anders machen kann.

Macht man es anders lassen sich problemlos zig tausende von Seiten halten.

Punkt b lässt sich leicht nachvollziehen betrachten wir einfach einmal den code für ein Seitenupodate:
Mysql über Myisam sperrt bei insert, delete und update die komplette Tabelle für den Moment der SQL Aktion.

Hier klicken, um den Code zum Kopieren zu markieren

    */
    protected function Update()
    {
      $gCms = cmsms();
      global $debug_errors;
      $db = $gCms->GetDb();
      $config = $gCms->GetConfig();

      $result = false;

#Figure out the item_order (if necessary)
      if ($this->mItemOrder < 1)
	{
	  $query = "SELECT ".$db->IfNull('max(item_order)','0')." as new_order FROM ".cms_db_prefix()."content WHERE parent_id = ?";
	  $row = $db->GetRow($query,array($this->mParentId));

	  if ($row)
	    {
	      if ($row['new_order'] < 1)
		{
		  $this->mItemOrder = 1;
		}
	      else
		{
		  $this->mItemOrder = $row['new_order'] + 1;
		}
	    }
	}

      $this->mModifiedDate = trim($db->DBTimeStamp(time()), "'");

      $query = "UPDATE ".cms_db_prefix()."content SET content_name = ?, owner_id = ?, type = ?, template_id = ?, parent_id = ?, active = ?, default_content = ?, show_in_menu = ?, cachable = ?, secure = ?, page_url = ?, menu_text = ?, content_alias = ?, metadata = ?, titleattribute = ?, accesskey = ?, tabindex = ?, modified_date = ?, item_order = ?, markup = ?, last_modified_by = ? WHERE content_id = ?";
      $dbresult = $db->Execute($query, array(
					     $this->mName,
					     $this->mOwner,
					     strtolower($this->mType),
					     $this->mTemplateId,
					     $this->mParentId,
					     ($this->mActive == true         ? 1 : 0),
					     ($this->mDefaultContent == true ? 1 : 0),
					     ($this->mShowInMenu == true     ? 1 : 0),
					     ($this->mCachable == true       ? 1 : 0),
					     $this->mSecure,
					     $this->mURL,
					     $this->mMenuText,
					     $this->mAlias,
					     $this->mMetadata,
					     $this->mTitleAttribute,
					     $this->mAccessKey,
					     $this->mTabIndex,
					     $this->mModifiedDate,
					     $this->mItemOrder,
					     $this->mMarkup,
					     $this->mLastModifiedBy,
					     $this->mId
					     ));

      if (!$dbresult)
	{
	  if (true == $config["debug"])
	    {
	      # :TODO: Translate the error message
	      $debug_errors .= "<p>Error updating content</p>\n";
	    }
	}

      if ($this->mOldParentId != $this->mParentId)
	{
#Fix the item_order if necessary
	  $query = "UPDATE ".cms_db_prefix()."content SET item_order = item_order - 1 WHERE parent_id = ? AND item_order > ?";
	  $result = $db->Execute($query, array($this->mOldParentId,$this->mOldItemOrder));

	  $this->mOldParentId = $this->mParentId;
	  $this->mOldItemOrder = $this->mItemOrder;
	}

      if (isset($this->mAdditionalEditors))
	{
	  $query = "DELETE FROM ".cms_db_prefix()."additional_users WHERE content_id = ?";
	  $db->Execute($query, array($this->Id()));

	  foreach ($this->mAdditionalEditors as $oneeditor)
	    {
	      $new_addt_id = $db->GenID(cms_db_prefix()."additional_users_seq");
	      $query = "INSERT INTO ".cms_db_prefix()."additional_users (additional_users_id, user_id, content_id) VALUES (?,?,?)";
	      $db->Execute($query, array($new_addt_id, $oneeditor, $this->Id()));
	    }
	}

      if( is_array($this->_props) && count($this->_props) )
	{
	  // :TODO: There might be some error checking there
	  $this->_save_properties();
	}
      else
	{
	  if (true == $config["debug"])
	    {
	      # :TODO: Translate the error message
	      $debug_errors .= "<p>Error updating : the content has no properties</p>\n";
	    }
	}

      cms_route_manager::del_static('','__CONTENT__',$this->mId);
      if( $this->mURL != '' )
	{
	  $route = CmsRoute::new_builder($this->mURL,'__CONTENT__',$this->mId,null,TRUE);;
	  cms_route_manager::add_static($route);
	}
    }

Hier sieht man das bereits die Festlegung von new_order in die Hosen gehen kann, wenn zufällig eine weitere Person da herum rubbelt.

Das würde aber bereits bei der eigentlichen Update Anweisung Konsequenzen haben.

Und die Tabellensperrung der ersten Updateanweisung wird sofort danach wieder aufgehoben - hier könnte bereits der nächste Fehler laufen.
Da in der zweiten möglichen Updateanweisung Werte aus dem ersten verwendet werden haben sich bereits erhebliche Probleme eingeschlichen.

Es werden praktisch keine Fehler mehr nach der ersten Updateanweisung aufgefangen.

Je mehr Seiten, je mehr Backenduser und je höher die Traffic im Frontend ist desto gefährlicher ist das - und - derartige Dinge gibt es x mal.

Beim konkreten Problem hier vermute ich das in Teilbereichen eine Tabellenstörung vorliegt die dazu führt das rekursiv alles zig mal abgeklappert wird bis man einen RAM Überlauf hat.

Da hilft nur genaue Kenntnis und manuelle Durchsicht aller Datensätze.

mike-r · 17. April 2013 13:07

cyberman schrieb:

cyberman schrieb:
cyberman schrieb:
Aber irgend wie war mir, als ob damals eine Änderung in der DB Abhilfe geschaffen hätte, indem das Feld, wo der (geöffnete) Seitenbaum gespeichert wird, von TEXT auf auf MEDIUM TEXT geändert wurde ...
OK, habs gefunden und hier publiziert.
Hattest du dies gecheckt?

Nein, bisher nicht, nun gerade nachgeholt: keine Änderung. (Es geht mir auch gar nicht darum, den kompletten Seitenbaum in der Seitenübersicht zu öffnen, sondern erstmal überhaupt eine Seite (über den eingeklappten oder nur teilweise geöffneten) zu bearbeiten)

czarnowski schrieb:

Beim konkreten Problem hier vermute ich das in Teilbereichen eine Tabellenstörung vorliegt die dazu führt das rekursiv alles zig mal abgeklappert wird bis man einen RAM Überlauf hat.

Würde ich nicht ausschliessen, meine cms_content_props hat 25MB (vs max 2MB in allen anderen Tabellen), kann mal bitte jemand mit vielen Seiten nachschauen, wie gross die da ist?

Edit: Die content_props ist für die Seiteninhalte zuständig, sehe ich das richtig? Die würde das Problem wahrscheinlich nicht verursachen. Oder wo genau liegt der Seitenbaum?

Beitrag geändert von mike-r (17. April 2013 13:23)

czarnowski · 17. April 2013 15:53

Wie man an der geposteten Funktion erkennen kann liegen die Informationen in der Tabelle cms_content.
Die kann man sich mit PMA und SQL so ausgeben das man für sich einen sinnvollen Zusammenhang hat.

In content_props stecken die Inhalte.

Andynium · 17. April 2013 20:31

czarnowski schrieb:

Beim konkreten Problem hier vermute ich das in Teilbereichen eine Tabellenstörung vorliegt

Lässt sich so etwas durch ein repair/optimize auf die Tabelle beheben?

czarnowski · 17. April 2013 21:04

Repair repariert lediglich erkennbare Fehler in der Tabelle selbst.

Ich habe den Verdacht das durch mangelnde Konsistenz der Daten es etwas mit der parent_id wäre.

Es gibt die Funktion

Hier klicken, um den Code zum Kopieren zu markieren

 public static function load_from_list($data,$parent_id = -1,cms_content_tree &$tree = null)
  {
    for( $i = 0; $i < count($data); $i++ )
      {
	$row = $data[$i];
	if( $row['parent_id'] < $parent_id ) continue;
	if( $row['parent_id'] > $parent_id ) break;

	// create a tree object
	if( !is_object($tree) ) 
	  {
	    $tree = new cms_content_tree();
	  }

	$node = new cms_content_tree(array('id'=>$row['content_id'],'alias'=>$row['content_alias']));
	self::load_from_list($data,$row['content_id'],$node);
	$tree->add_node($node);
      }
    return $tree;
  }
}

in class.cms_tree_operations.php die sich u.U. permanent selbst und unendlich aufrufen kann wenn da Operationen bei insert, delete oder update nicht vollständig geklappt haben - also da wäre mein Verdacht.
Zudem würde es den exorbitanten Verbrauch an RAM erklären der zum Abpfiff führt.

Bei einer Durchsicht der Tabelle sollte man sich also die parent_id's manuell vornehmen - ist aber eine Schweinearbeit.

Andynium · 17. April 2013 21:25

czarnowski schrieb:

Die Ursachen sind aus meiner Sicht vielfältig
a. das Menüsystem ist völlig unwirtschaftlich aufgebaut
b. die Konsistenz der Daten ist nicht gesichert
Das aber habe ich bereits vor vielen Jahren geäussert und auch an Beispielen belegt wie man es anders machen kann.

Meinst du jetzt damit Pimenu / Powermenu?

mike-r · 18. April 2013 10:12

czarnowski schrieb:

Bei einer Durchsicht der Tabelle sollte man sich also die parent_id's manuell vornehmen - ist aber eine Schweinearbeit.

Ärm, wonach schaue ich da, und in welcher Tabelle?

Ich habe jetzt einmal die cms_content durchgesehen und für mich als Laie sieht da nichts auffällig aus.

Ausser, dass wir nicht von 600 Seiten reden ... sondern von knapp 1500 yikes

czarnowski · 18. April 2013 11:25

Zunächst einmal schauen (in content) ob irgendwo parent_id irgendwo null oder -2 ist.
In dem Fall kommt es zu zusätzlichen Schleifen - die machen bei der Standardinstallation fast 1 MB mehr Speicherbedarf aus nur wenn man eine einzige Seite händisch auf -2 ändert.

In addcontent,php halte ich

$parent_id = get_preference($userid, 'default_parent', -2);

für einen Fehler müsste

$parent_id = get_preference($userid, 'default_parent', -1);

sein
------------

@cyberman
pimenu powermenu sind ja Beispiele aber auch bereits total veraltet.

Heute wäre der Stand der Dinge das man sich entweder die komplette Hierarchie vollständig komplett mit einer einzigen SQL Abfrage holt bzw. Unterpunkte komplett ebenfalls mit einer einzigen Abfrage.

contentcache habe ich schon vor Jahren ersatzlos gestrichen da bei Last unterm Strich es erheblich mehr kostet als es überhaupt bringt.

In den aktuellen kommerziellen Versionen der Nachfolger von Pcms (pcms gibt es nicht mehr als OS) wird längst nested Set verwendet - da wird es noch einfacher.

Beitrag geändert von czarnowski (18. April 2013 11:26)

Forum für CMS/made simple

#51 02. April 2013 16:33

Re: Fatal error: Allowed memory size of 33554432 bytes exhausted

#52 11. April 2013 12:53

Re: Fatal error: Allowed memory size of 33554432 bytes exhausted

#53 11. April 2013 13:42

Re: Fatal error: Allowed memory size of 33554432 bytes exhausted

#54 11. April 2013 15:50

Re: Fatal error: Allowed memory size of 33554432 bytes exhausted

#55 11. April 2013 16:42

Re: Fatal error: Allowed memory size of 33554432 bytes exhausted

#56 11. April 2013 17:11

Re: Fatal error: Allowed memory size of 33554432 bytes exhausted

#57 11. April 2013 20:36

Re: Fatal error: Allowed memory size of 33554432 bytes exhausted

#58 12. April 2013 23:31

Re: Fatal error: Allowed memory size of 33554432 bytes exhausted

#59 12. April 2013 08:34

Re: Fatal error: Allowed memory size of 33554432 bytes exhausted

#60 15. April 2013 21:25

Re: Fatal error: Allowed memory size of 33554432 bytes exhausted

#61 16. April 2013 07:40

Re: Fatal error: Allowed memory size of 33554432 bytes exhausted

#62 16. April 2013 08:23

Re: Fatal error: Allowed memory size of 33554432 bytes exhausted

#63 16. April 2013 10:02

Re: Fatal error: Allowed memory size of 33554432 bytes exhausted

#64 16. April 2013 20:08

Re: Fatal error: Allowed memory size of 33554432 bytes exhausted

#65 16. April 2013 21:05

Re: Fatal error: Allowed memory size of 33554432 bytes exhausted

#66 16. April 2013 21:58

Re: Fatal error: Allowed memory size of 33554432 bytes exhausted

#67 17. April 2013 05:15

Re: Fatal error: Allowed memory size of 33554432 bytes exhausted

#68 17. April 2013 11:39

Re: Fatal error: Allowed memory size of 33554432 bytes exhausted

#69 17. April 2013 13:07

Re: Fatal error: Allowed memory size of 33554432 bytes exhausted

#70 17. April 2013 15:53

Re: Fatal error: Allowed memory size of 33554432 bytes exhausted

#71 17. April 2013 20:31

Re: Fatal error: Allowed memory size of 33554432 bytes exhausted

#72 17. April 2013 21:04

Re: Fatal error: Allowed memory size of 33554432 bytes exhausted

#73 17. April 2013 21:25

Re: Fatal error: Allowed memory size of 33554432 bytes exhausted

#74 18. April 2013 10:12

Re: Fatal error: Allowed memory size of 33554432 bytes exhausted

#75 18. April 2013 11:25

Re: Fatal error: Allowed memory size of 33554432 bytes exhausted

Fußzeile des Forums