Druckbare Version
Fatal error: Allowed memory size of 16777216 bytes exhausted (tried to allocate 524234 bytes) in /var/www/web157/html/_typolight_ft/system/modules/BackupDBplus/backup.inc.php on line 271
Hat die Meldung schon mal jemand gehabt und eine Lösung dafür? Mein Memory limit ist auf 16M, also ein Recommended setting.
Andreas
Der Wert wird in der php.ini und/oder der vhost.conf des Servers deklariert.
In Frage könnte aber auch eine PHP-Direktive innerhalb eines Scriptes kommen, z.B. in dieser Form:
In einer php Datei deklariert und an falscher Stelle eingesetzt, wird der Wert für das komplette TL überschreiben.Code:@ini_set('memory_limit', '16M');
Wird der Wert dann überschritten, erscheint diese Meldung.
Ich meine gelesen zu haben, dass TL mehr als 16mb benötigt, kann mich da aber jetzt täuschen. Finde nach dem Relaunch die Stelle gerade nicht, sorry.
Man darf den Wert auch nicht zu hoch nehmen, da der Server dann anfängt unruhig zu werden. ;)
16MB sollte auch fyr eine normale Seite ausreichen.Zitat:
Zitat von Andreas
Tritt das Problem auf jeder Seite auf?
Wenn nein, dann untersuche doch mal welche Module auf den Seiten liegen die nicht funktionieren.
Obendrein koenntest du testweise die Erweiterungen im BE deaktivieren, bis du den Schuldigen gefunden hast.
Gruss
Chris
Ups, sorry, ich dachte das wäre klar, dass ich mich auf das BackUp der Datenbank mit BackUpDBplus beziehe, da ich es hier in das Forum gestellt habe.
Also zur Ergänzung: Es passiert beim Versuch ein BackUp mit BackUpDBplus zu erstellen.
Gibt es eine neuere typolight-check.php? Bei meiner steht "Recommended setting is 16M or greater".
@Thomas
Mein Provider bietet mir 16MB, ohne dass ich dies gepuscht hätte. Auch in der typolight-check.php bekomme ich dieses ja auch angezeigt.
Manueller DB-Dump sind ca 4.3MB als unkomprimierte sql-Datei.
Andreas
Das Problem ist, dass der PHP-Interpreter voll läuft.
Du kannst mal eins versuchen:
Testweise in eine PHP-Datei schreiben, die möglichst gleich am Anfang geladen wird.Code:@ini_set('memory_limit', '18M');
Mir düngt, dass der Memory nur um einen ganz geringen Teil überschritten wird.
Wenn das nicht funktioniert, den Provider ansprechen, ob er ihn um 1-2 MB anheben kann oder gar gleich auf 32MB.
Hast du auf die Schnelle auch eine Möglichkeit parat, wie ich das mit der .htaccess steuern kann?
Ja, das ginge auch:
Hängt natürlich davon ab, ob dein Provider das ermöglicht.Code:php_value memory_limit 24M
Aber einen Versuch ist es Wert.
Auf einem Webspace glaube ich da aber nich so ganz dran. ;)
Hab den Eintrag jetzt in die dcaconfig.php gesetzt. Mit 18M gab es folgendes:
Fatal error: Allowed memory size of 18874368 bytes exhausted (tried to allocate 690344 bytes) in /var/www/web157/html/_typolight_ft/system/modules/BackupDBplus/backup.inc.php on line 273
Mit 32M ging es dann.
Ist das normal, dass mein manueller Dump 4,3MB und mit BackUpDBplus 1,7MB groß ist?
Andreas
Ne, geht nicht, gibt Fehlermeldung. Is doch richtig, dass da kein Semikolon ans Ende kommt, oder?Zitat:
Zitat von Thomas
Das kommt auf die Kompression an!Zitat:
Ist das normal, dass mein manueller Dump 4,3MB und mit BackUpDBplus 1,7MB groß ist?
Wenn alle Daten ohne Fehler vorhanden sind, ist das ja auch nicht weiter schlimm.
Ich nutze für sowas auch nicht mehr die phpMyAdmin Routine sondern MYSQL Dumper. Somit entgehe ich auch gleich der Gefahr, größere Dumps teilen zu müßen.
Ja, das ist richtig.Zitat:
Ne, geht nicht, gibt Fehlermeldung. Is doch richtig, dass da kein Semikolon ans Ende kommt, oder?
Allerdings muß der Provider das explizit zulassen (Servereinstellung), über PHP gehts dagegen immer. ;)
Ich würde mich dennoch, dem Provider gegenüber absichern und lieber nach einer Erhöhung fragen. Ich weiß nicht ob derartige Manipulation die AGBs wiedergeben. ;)
Mmh, phpMyAdmin Dump ist unkomprimiert, aber ein Blick in den BackUpDBplus Dump sieht auch unkomprimiert aus. Wie kann ich denn jetzt feststellen, ob die Daten übereinstimmen?
Bevor ich's im Eifer des Gefechts vergesse: schon mal vielen Dank für die vielen Infos, die ich bis jetzt bekommen habe :D
Keine Ursache! :)
Du kannst die Dumps einfach mal mit einem Texteditor öffnen.
Sind die Zeilen gleich, dürfte sich an den Daten kaum was geändert haben.
Ich bevorzuge generell Dumps von Hand einzuspielen, sollte es mal nötig werden.
So bin ich gewiss, dass mir ein Scriptfehler nicht in die Suppe spuckt. ;)
MYSQL Dumper hat im übrigen auch eine Cronfunktion. ;)
Ich werde mir MYSQL Dumper mal ansehen. Diese beiden unterschiedlichen SQLs kann ich nicht so ohne weiteres vergleichen, da eine 1,7 und eine 4,3 MB groß ist. Das heißt, dass natürlich ein großer Unterschied zwischen ihnen besteht. Wichtig ist mir nur, dass ich mich darauf verlassen kann, das ALLE Daten gesichert sind.
Danke nochmal :D
Hallo Andreas,
bin gerade von der Ostsee zurück. Ich habe in den letzten Tagen vor menem Urlaub auch geschafft, diesen Fehler zu bekommen. Offenbar ist BackupDBPlus da viel anfälliger als das BackupDB. Ich werde mir das in den nächsten Tagen genau anschauen müssen.
Zu Deinen beiden Backups verschiedener Größe:
Die Datenbanksicherung von BackupDBPlus muss am Ende eine Kommentarzeile "# --- End of Backup ---" enthalten, dann sollte auch alles enthalten sein und nicht vom Runtime-Limit beendet worden sein.
Es kann sein, dass der Dump von phpMyAdmin viel größer ist, das kommt darauf an, welche Optionen Du beim Export eingestellt hast.
BackupDB geht beim Komplettbackup einer Tabelle davon aus, dass durch die vorgesetzte Strukturdefinition nicht jeder Datensatz mit Felddefinitionen erstellt werden muss. Anders ist es bei Website-Template, da dort die Datenbank bereits vorhanden ist und mit dem Template befüllt werden soll. Hier sind die Felder ggf. in anderer Reihenfolge und daher müssen die Datensätze die Feldnamen enthalten.
Beim Backup wird im Ernstfall die Struktur neu aufgesetzt und dann stimmt die Reihenfolge immer. Ich brauche die Feldnamen also nicht in jedem Datensatz wiederholen. Wenn das aber beim phpMyAdmin-Export anders eingestellt ist wird jeder Datensatz um viele Zeichen länger. Wenn in einer Tabelle nur wenige Datenbytes enthalten sind, kann das große Unterschiede ausmachen.
Wegen der BackupDBPlus-Meldungen melde ich mich in den nächsten Tagen ...
Das hört sich gut an! ;)
hallo @all
habe das gleiche problem mit dem speicher wie andreas. nachdem die erste fehlermeldung
lautete, habe ich den provider gebeten den speicher ein bisschen zu erhöhen. er hat mir das ganze auf 32mb erhöht, nun bekomme ich diesen fehlerCode:Fatal error: Allowed memory size of 16777216 bytes exhausted
(tried to allocate 1834976 bytes) in
/var/www/web59/web/system/modules/BackupDB/MakeWsTemplateRun.php
on line 152
es handelt sich um BackupDB 1.1.1 stable build 8 auf TL 2.7.2Code:Fatal error: Allowed memory size of 33554432 bytes exhausted
(tried to allocate 3223854 bytes) in
/var/www/web59/web/system/modules/BackupDB/MakeWsTemplateRun.php
on line 154
hat jemand eine idee was da nicht stimmt?
Hallo kretschi,
unabhängig davon, dass es schön wäre wenn backupDB mit den recommended TL settings laufen würde: Ich mach meine DB-backups jetzt mit MySQLDumper und die Datei-backups mit REOBack. Aus diesem Grund hab ich das hier nicht mehr weiter verfolgt.
Andreas
hallo andreas,Zitat:
Zitat von Andreas
wobei ich vergessen habe zu sagen, dass der fehler nur auftritt wenn man das template sichern möchte. der DB backup als dump funktioniert problemlos.
Genau solche Fehler sind es vor geraumer Zeit gewesen, mich nach Allternativen umzusehen und mich nicht mehr auf Scripte in dieser Form zu verlassen.
Damals mußte ich eine 120 mb große Datenbank sichern.
MYSQLDumper hat noch einen riesen Vorteil, man kann über Cronjobs genau festgelegte Bereiche der DB sichern und kann so die Dumps klein halten und Tabellen, die sich ständig mit Inhalten ändern von quasi statischen trennen.
@kretschi
Bei Dir ist es das Selbe, der Interpreter läuft voll.
Mit einem Eintrag in die htaccess kannst Du ja mal testen, in welche Höhe Du den Wert des Memorys schrauben mußt. Vermutlich wird Dir Dein Anbieter vorschlagen das Script zu ändern. :)
Versuche es allternativ mal mit MYSQLDumper.
Hallo,
BackupDB eignet sich nicht für größere Datenbanken, da es beim Sichern an die Speichergrenzen stoßen kann oder ggf. auch die PHP-Laufzeit nicht ausreicht. Normal kleine Projekte sollten aber laufen.
Für große Datenmengen ist sicherlich MySQLDumper die bessere Lösung, da dabei die SQL-Daten auch komprimiert gespeichert werden können.
Ergänzend zu Thomas: Ja, mach ich auch beides mit Cron-Job. DB und Dateien. Außerdem kannst du mit beiden Tools die Sicherungen gleichzeitig auf einen 2. Server doppeln.
Andreas
danke für die infos. habe es gestern via mysqldumper erledigt.
ja super :D willkommen im Club
Andreas
Hi
ich habe inzwischen 64MB und beim Speichern mit BackupDB+ platzt die Sache
Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 778088 bytes) in /var/www/html/system/modules/BackupDBplus/backup.inc.php on line 293
muss man die ganze DB in einer Variablen "auffangen"? - eine (ggf. temp.) Datei + Zip wäre doch machbar... oder?Code:public function getDbBackup( $tables, $createtab = true )
{
if( !count($tables) ) return ''; // keine Tabellen, leeres Array zurückgeben
$result = ''; // Ergebnisvariable vorbereiten
foreach( $tables as $table ) {
$dbStruct = $this->getDbStructure( $table );
$content = $this->getDbTableContent( $table, $dbStruct['insertInto'] );
if( $createtab ) {
$result .= $dbStruct['createTable']; // Table structure
}
if( strlen( $content ) > 5 ) {
$result .= "\r\n#\r\n# Table '$table'\r\n#\r\n" . $content."\r\n"; // hier #293
}
}
return $result;
}
Gruss zonky
PS: der Dumper wäre sicher machbar - alles "in einer Hand" hat auch was für sich...
Hallo zonky,
Du hast Recht, da sollte einiges verbessert werden. Leider fehlt mir im Moment die Zeit für diese Erweiterung, die im Übrigen auch für 2.9.x nicht freigegeben ist.