Fatal error: Allowed memory size of 33554432 bytes exhausted

Andynium · 26. Juli 2011 22:05

chica2 schrieb:

Kann es sein dass ich z.B. alle UDT jetzt umschreiben muss ?

Sollte doch kein Problem sein, oder?!

chica2 schrieb:

Aber würde das den enormen memory bedarf erklären?

Nee, nicht wirklich ... bist du schon auf der aktuellen CMSMS-Version?

chica2 · 30. Juli 2011 14:35

Es muss doch ein Fehler im CMSms script sein:
habe hier einige Fehlermeldungen gesammelt, die eben nur ab und zu auftreten:

1. http://web.url.org/cms/
Fatal error: Using $this when not in object context in /is/htdocs/wpzzzzz-zzz/www/pfad/cms/lib/translation.functions.php on line 153

hier das script dazu :zeile 153 : $curlang = $this->config['locale'];

Hier klicken, um den Code zum Kopieren zu markieren

[== php ==]
function cms_frontend_current_language() {   global $gCms;   $curlang = get_site_preference('frontendlang','');   if (isset($gCms->config['locale']) && $gCms->config['locale'] != '') {     $curlang = $this->config['locale'];   }   if( $curlang == '' ) {     $curlang = 'en_US';   }    return $curlang; }

2. http://web.url.org/cms/
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 26331371 bytes) in /is/htdocs/wpzzzzz-zzz/www/pfad/cms/admin/footer.php on line 102

hier das script dazu :
zeile 102: $htmlresult = str_replace('', $footertext, $htmlresult);

3. und wenn man diese URL mit dem footer.php aufruft :
http://web.url.org/cms/admin/footer.php
erscheint:
Fatal error: Call to a member function DisplayMainDivEnd() on a non-object in /is/htdocs/wpzzzzz-zzz/www/pfad/cms/admin/footer.php on line 8
zeile 8: $themeObject->DisplayMainDivEnd();
hier das script dazu :

Hier klicken, um den Code zum Kopieren zu markieren

[== php ==]
< if (isset($USE_THEME) && $USE_THEME == false)   {     echo '<!-- admin theme disabled -->'; } else  {     $themeObject->DisplayMainDivEnd();     $themeObject->OutputFooterJavascript();    $themeObject->DisplayFooter();  }

Hat jemand eine Idee, was hier falsch sein könnte???

zu deiner Frage : habe die Version:CMS Made Simple 1.8.1 "Mankara",
Wenn es sein muss, dann werde ich eben das System upgraden. Ich zögere damit, denn das ist doch auch nicht immer unproblematisch, weil danach evtl manche Module nicht laufen...

Vielen Dank für eure Hilfe!!!

NaN · 30. Juli 2011 17:59

1. ist ein Fehler im CMS. Wurde in der Version 1.8.2 behoben.

3. ist logisch, weil die Datei footer.php nicht dazu gedacht ist, direkt aufgerufen zu werden. Sie wird in einer anderen Datei mittels include eingebunden.

Warum bei 2. Dein Speicher volläuft kann ich nicht sagen.
In der footer.php wird versucht, ganze 26 MB (!!!) zu belegen. Das ercheint mir recht viel. Mal ganz davon abgesehen, dass dann immer noch ca. 100 MB im Backend belegt wären, was ebenfalls viel zu viel ist. Um 100 MB voll zu kriegen, müsstest Du schon sehr viele Module laden bzw. müssten diese Module schon beim Laden mit sehr viel Daten rumhantieren, was ungewöhnlich ist.

Was in der footer.php gemacht wird, ist unter anderem folgendes: Es werden alle installierten und aktiven Module durchgegangen und deren Modul-Funktionen

WYSIWYGGenerateBody()
WYSIWYGGenerateHeader($htmlresult)
WYSIWYGPageForm()
WYSIWYGPageFormSubmit()

SyntaxGenerateBody()
SyntaxGenerateHeader($htmlresult)
SyntaxPageForm()
SyntaxPageFormSubmit()

aufgerufen. Dadurch können Module bestimmte Änderungen an der eigentlichen HTML Ausgabe vornehmen (z.B. eigenes Javascript/Stylesheet hinzufügen etc.). Bei irgendeinem Modul könnte eine dieser Funktionen enorm viel Daten transportieren, was ebenfalls äußerst ungewöhlich wäre.

Um dem Problem auf die Schliche zu kommen, versuch mal folgendes:
Kommentiere mal in der footer.php die Zeile 61 und 86:

Hier klicken, um den Code zum Kopieren zu markieren

$loadit=true;

aus:

Hier klicken, um den Code zum Kopieren zu markieren

#$loadit=true;

Somit kann man zumindest meinen Verdacht, dass es an einem Modul und einer dieser Funktionen liegen könnte. bestätigen bzw. auch entkräften. Das Auskommentieren bewirkt, dass diese Modulfunktionen nicht ausgeführt werden. Dadurch kann es unter Umständen passieren, dass einige Funktionen wie z.B. der TinyMCE nicht mehr korrekt funktionieren, weil eben bestimme Daten fehlen. Das soll also noch keine Lösung sein, sondern dient nur zum Testen, ob der Speicher tatsächlich an dieser Stelle volläuft oder nicht.

Wenn das nicht viel bringt, dann deaktiviere mal jedes Modul einzeln und schau nach, ab wann der Fehler nicht mehr auftritt. Dann weißt Du welches Modul so viel Speicher verbraucht. Wenn das auch nichts bringt, dann liegt das Problem möglicherweise woanders.

Außerdem fragtest Du, ob Du nun alle UDTs in Plugins ändern sollst.
Das alleine kann zwar zu etwas mehr Performance in Sachen Geschwindigkeit führen, wird Dein Speicherproblem aber nicht beheben. Jedoch wäre es vielleicht ganz gut, mal zu prüfen, was genau diese UDTs eigentlich machen.

Andynium · 30. Juli 2011 18:34

In der letzten Zeit hatten wir auch ein paar Meldungen zu viel über gehackte / manipulierte CMSMS-Installationen - evtl. wäre es auch eine gute Idee, die 1.8.1er CMSMS-Core-Dateien komplett neu hochzuladen roll ...

NaN · 31. Juli 2011 22:13

cyberman schrieb:

In der letzten Zeit hatten wir auch ein paar Meldungen zu viel über gehackte / manipulierte CMSMS-Installationen - evtl. wäre es auch eine gute Idee, die 1.8.1er CMSMS-Core-Dateien komplett neu hochzuladen ...

Und nach Möglichkeit die Fehler bzw. Sicherheitslücken sofort von Hand zu beheben - falls Du noch nicht auf CMSms 1.9.4.2 updaten kannst/willst.

Connie · 23. Dezember 2012 10:09

Hallo Ihr Lieben,

ich habe auch eine komische Situation mit einer leiden alten Installation 1.7.1, die ich nicht updaten kann da dann einige der Module nicht laufen, ich traue mich das nicht weil ich es nicht versauen möchte und im Moment nicht die Zeit habe, das in Ruhe in einer Parallel-Installation zu testen...

also die Situation ist diese:
nur bei einem bestimmten User kommt die Meldung
" Allowed memory size of 33554432 bytes exhausted (tried to allocate 450904 bytes) in /var/www/..../.../admin/listcontent.php on line 1240"

der hat alle Rechte. Zwischenspeicher habe ich gelöscht. Wenn ich einen anderen User anlege mit den gleichen Rechten oder andere User sich anmelden, können die alle Seiten auflisten und arbeiten, nur dieser eine User nicht.

ich mach jetzt mal nen Extradump und repariere dann mal die Datenbank, aber eigenartig ist es schon

Habt Ihr eine Idee?

nockenfell · 23. Dezember 2012 11:08

Wieviele Unterseiten hat die Seite? Es wird jeweils pro User gespeichert wie der Seitenbaum geöffnet ist. Wenn dieser User nun fast den gesamten Seitenbaum offen hat, kann es dazu kommen, dass mehr Speicher benötigt wird, als vorhanden. Möglich das dies mit der 1.10 oder 1.11er ein wenig entschärft wurde (zumindest schon länger keine solche Meldung mehr gelesen).

Als Lösungsansatz: PHP Memory Limite hochsetzen.

Andynium · 23. Dezember 2012 15:06

Das Problem hatten wir vor langer Zeit in einem der Foren (weiß nur nicht mehr, in welchem wink ) 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 roll ...

Connie · 24. Dezember 2012 09:08

Ach Ihr Lieben,

da gehe ich jetzt mal auf die Suche. Wollte nachschauen, wieiviele Unterseiten das hat, und da passiert es auch meinem User...

na da muss ich mal in die Datenbank schauen, hoffentlich kann ichs bereinigen, sonst wird das nichts mehr diese Weihnachten ... der Kunde will sein Jahres-Kursprogramm publizieren...

danke für die Tipps, ich melde mich!

Connie

Connie · 24. Dezember 2012 09:49

Hallo Ihr Lieben,

es war das Problem mit dem Seitenbaum. Ich kanns nicht fassen, das ist ein Problem das sich durch alle Versionen zu ziehen scheint.

Da ich auf dem Server viel "darf" hab ich in der config.php das Memory Limit auf 64MB hochgesetzt und nun funktioniert es. Mit allen Usern.

"ini_set('memory_limit','64M');"

Ich meine die Seite ist nun wirklich nicht so gross, daß ein CMS solcherart in die Grätsche geht... das dürfte nicht sein.

Als schnelle Lösung werde ich den Anwendern raten, falls wir dann nach weiteren 50 Seiten 128 MB brauchen sollten müssten, erstmal

"&collapseall=1"

hinten an die URL zu hängen und nur den Baum-Ast zu expandieren, wo sie arbeiten wollen.

Liebe Grüsse und frohe Weihnachten!

Connie

Andynium · 24. Dezember 2012 20:25

Connie schrieb:

Ich meine die Seite ist nun wirklich nicht so gross, daß ein CMS solcherart in die Grätsche geht... das dürfte nicht sein.

Was laufen denn da CMSMS-seitig noch für Module?

Connie · 28. Dezember 2012 19:10

das ist in der Installation:

----------------------------------------------

Cms Version: 1.7.1

Installed Modules:

CMSMailer: 2.0
FileManager: 1.0.2
MenuManager: 1.6.3
ModuleManager: 1.3.3
News: 2.10.5
nuSOAP: 1.0.1
Printing: 1.0.4
Search: 1.6.3
ThemeManager: 1.1.1
TinyMCE: 2.7.0
CGExtensions: 1.19
Cataloger: 0.7.7
CGGoogleMaps: 1.4.1
FCKeditorX: 1.1.0
SiteMapMadeSimple: 1.2.1
FormBuilder: 0.6.2
LinkMgr: 1.5.1
NMS: 2.3.2
DownloadManager: 1.4.1
Play: 1.0.3
Uploads: 1.11.2
SimpleViewer: 1.0
avplayer: 1.3
CGSimpleSmarty: 1.4.5
CGBlog: 1.4
CGFeedback: 1.2

Config Information:

php_memory_limit:
process_whole_template: true
max_upload_size: 12582912
default_upload_permission: 664
assume_mod_rewrite: true
page_extension: .html
internal_pretty_urls: false
use_hierarchy: true

Php Information:

phpversion: 5.2.6-1+lenny10
md5_function: An (Ja)
gd_version: 2
tempnam_function: An (Ja)
magic_quotes_runtime: Aus (Nein)
E_STRICT: 0
memory_limit: 64M
max_execution_time: 300
safe_mode: Aus (Nein)
session_save_path: /var/lib/php5 (1733)
session_use_cookies: An (Ja)

Server Information:

Server Api: cgi-fcgi
Server Db Type: MySQL (mysql)
Server Db Version: 5.0.51a

----------------------------------------------

Gruss, Connie

Andynium · 30. Dezember 2012 17:55

Werden tatsächlich alle Module auf der Webseite verwendet?

Bei der Anzahl der Module (und dabei der Performance Eater Formbuilder) ist es kein Wunder, dass die Installation in die Grätsche geht - die werden ja jedes Mal mitgeladen (war zumindest bei deiner Version noch so). Hat sich aktuell durch das sogenannte Lazy Loading etwas entschärft.

Connie · 01. Januar 2013 15:51

danke für die Infos! Ich werde mal ein paar der Module ausmisten, aber der Formbuilder ist unabdingbar...

Lieber Gruss und ein gutes Neues Jahr und grossen Dank für deinen Einsatz für CMSMS!

Connie

czarnowski · 01. Januar 2013 22:43

Das Memory Problem ist bei CMSMS ein Designproblem dem ohne grundlegende Überarbeitung nicht beizukommen ist.

Einsatz von CMSMS eigentlich nur bei kleinen überschaubaren Sites mit weniger als 50 Seiten und vor allem mit einer sehr flachen Hierarchie - dann dürfte man auch bei normaler RAM Ausstattung kaum Probleme haben.( mit Ausnahme der Performance).

Der Einsatz einer Zahl X an Modulen steuert zwar bei aber die Reduzierung der Anzahl ist keineswegs die Lösung.

Connie · 02. Januar 2013 12:14

ja, das mag ja alles sein, aber bei der Entscheidung für CMSMS war das nicht bekannt und wer käme auf die Idee, ein solches Datenbank-basiertes System für gerade mal 50 Seiten zu nehmen?

für kleine Seiten gibt es Getsimple, das hat bei weitem nicht soviel Designfehler und Starrköpfe, aber für größere Seiten war eben CMSMS meine Wahl, wenn ich jetzt nochmal sowas umsetzen sollte, vielleicht Contao?

Klenkes · 02. Januar 2013 14:51

czarnowski schrieb:

Einsatz von CMSMS eigentlich nur bei kleinen überschaubaren Sites mit weniger als 50 Seiten und vor allem mit einer sehr flachen Hierarchie - dann dürfte man auch bei normaler RAM Ausstattung kaum Probleme haben.( mit Ausnahme der Performance).

Das kann man so pauschal nicht sagen.

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.

czarnowski · 03. Januar 2013 13:05

Klenkes schrieb:

Das kann man so pauschal nicht sagen.

Das ist richtig aber innerhalb dieser Grenzen dürften sich auch beim Einsatz einer Anzahl von Modulen normal keine oder selten Probleme ergeben.

Was die Performance betrifft wird immer wieder der Fehler gemacht sich auf die Zeiten zu verlassen die man sich ausgeben lassen kann.

Die sind zwar interessant aber zeigen keineswegs die echte Performance und zudem sind die Angaben wie auch die RAM Angaben seit Jahren geschummelt.Langsame Zeiten deuten lediglich darauf hin das die Performance unter Last drastisch abfallen wird.

Am besten beharkt man sein Web mal mit dem Apache Benchmark - damit wird die Applikation nebst den Serverfähigkeiten getestet.
Interessant ist da der Wert Requests per second.

Hier z.B. liegt sie aktuell bei Requests per second: 5.32 [#/sec] (mean)

Hier sah es eben so aus -n50 -c50

Server Software: Apache
Server Hostname: www.cmsmadesimple.de
Server Port: 80

Document Path: /index.php
Document Length: 104259 bytes

Concurrency Level: 50
Time taken for tests: 9.395 seconds
Complete requests: 50
Failed requests: 46
(Connect: 0, Receive: 0, Length: 46, Exceptions: 0)
Write errors: 0
Total transferred: 5233976 bytes
HTML transferred: 5213376 bytes
Requests per second: 5.32 [#/sec] (mean)
Time per request: 9394.511 [ms] (mean)
Time per request: 187.890 [ms] (mean, across all concurrent requests)
Transfer rate: 544.07 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 42 56 9.9 62 68
Processing: 337 5652 2481.9 5229 9331
Waiting: 243 5395 2421.4 4948 9017
Total: 380 5708 2489.7 5291 9394

Percentage of the requests served within a certain time (ms)
50% 5291
66% 7412
75% 7451
80% 7479
90% 9332
95% 9344
98% 9394
99% 9394
100% 9394 (longest request)

Der zweite interessante Wert ist der der Fehler:
Complete requests: 50
Failed requests: 46

Um Titel genau vergleichen zu können setzt man am besten den/die anderen Titel auf dem gleichen Space mit vergleichbaren Inhalt un prüft sie mit den gleichen Parametern.

Am besten macht man es lokal da man u.U. bei einigen Providern mit dem Test eine Sperre provozieren
könnte.

Bei deiner Domain sind die Werte unter Last ebenfalls sehr bescheiden:

ab -n50 -c50 http://www.ctlmm.com/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking www.ctlmm.com (be patient).....done

Server Software: Apache
Server Hostname: www.ctlmm.com
Server Port: 80

Document Path: /
Document Length: 12423 bytes

Concurrency Level: 50
Time taken for tests: 15.764 seconds
Complete requests: 50
Failed requests: 0
Write errors: 0
Total transferred: 641600 bytes
HTML transferred: 621150 bytes
Requests per second: 3.17 [#/sec] (mean)
Time per request: 15763.932 [ms] (mean)
Time per request: 315.279 [ms] (mean, across all concurrent requests)
Transfer rate: 39.75 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 93 106 26.2 94 165
Processing: 4256 12994 3456.6 15209 15670
Waiting: 3958 12575 3249.8 14517 15223
Total: 4349 13099 3460.4 15319 15763

Percentage of the requests served within a certain time (ms)
50% 15319
66% 15355
75% 15396
80% 15523
90% 15695
95% 15758
98% 15763
99% 15763
100% 15763 (longest request)

Man muss wissen das ein erheblich besserer Server keine lineare Verbesserung bedeutet, also ein 10 x leistungsfähigerer Webserver bringt nie 10 x bessere Performance.

Tatsächlich ist der Performanceunterschied zwischen normalen und HighSpeed Server so manches Mal enttäuschend gering.

Für normale Websites sollte man einen Wert um die 15 und besser erreichen können.
Bei extremen Websites gibt es Ansätze die dort locker um die 5000 schaffen können und das alles allein mit der Programmierung.

czarnowski · 03. Januar 2013 13:17

Connie schrieb:

ja, das mag ja alles sein, aber bei der Entscheidung für CMSMS war das nicht bekannt und wer käme auf die Idee, ein solches Datenbank-basiertes System für gerade mal 50 Seiten zu nehmen?

Auch wenn man immer noch auf Adodb Lite herum rubbelt - was nicht vorteilhaft ist - an der eigentlichen Datenbanknutzung liegt es nicht, da könnte man sogar ganz hervorragend mit Sqlite arbeiten.

Man darf nie davon ausgehen das ein auf DB basierendes System gut für 50,500,5000 oder X Seiten ist.
Jedes System muss es beweisen.

Entscheidend ist immer das Design des Systems und bei DB Abfragen deren Effizienz.

Das Design der Applikation insgesamt ist bei CMSMS nicht für dicke Sites ausgelegt.

czarnowski · 03. Januar 2013 13:52

Wer sich mit print_r den Inhalt der contentcache.php der Standardinstallation mal ausgeben lässt der erkennt ziemlich deutlich die Schwächen an den Punkten wo es abwärts in die Hierarchie geht (auf *RECURSION*) achten.
Das ist alles andere als gekonnt gelöst.

cms_content_tree Object
(
[_parent:cms_tree:private] =>
[_tags:cms_tree:private] =>
[_children:cms_tree:private] => Array
(
[0] => cms_content_tree Object
(
[_parent:cms_tree:private] => cms_content_tree Object
*RECURSION*
[_tags:cms_tree:private] => Array
(
[id] => 15
[alias] => home
)