Ich bekam immer wieder die Fehlermeldung Fatal error: Allowed memory size xxxx exhausted und da ich bei meinem Webhosting keinen Zugriff auf die php.ini habe, musste eine andere Lösung her.

Die Lösung ist sehr einfach, wenn man Zugriff auf die php.ini hat, dann muss man einfach folgenden Code hinzufügen bzw. ändern:

memory_limit = 32M;

Es kann passieren, dass auch dieser Wert zu niedrig ist, dann sollte man ihn noch einmal großzügig Schritt für Schritt erhöhen.

Viele Webhoster erlauben keinen Zugriff auf die php.ini, so kann man den Wert auch über die wp-config.php anpassen.

Einfach folgendes an oberster Stelle unterhalb dem <?php in der wp-config.php eintragen:

define(‘WP_MEMORY_LIMIT’, ’32M’);

Bei einem Update musste ich den Wert sogar auf 60M hochstellen, damit ich keine Fehlermeldung mehr erhalte.

Sehr ärgerlich, denn viele WordPress Nutzer sind gar nicht in der Lage sich so zu helfen.

Aus der Beschreibung des Verlages: Dieses Buch bietet Ihnen die effiziente Vorbereitung auf das vollständige MCSE-Examen zum Windows Server 2003 mit dem Schwerpunkt Messaging. Sie lernen eine Windows Server 2003-Testumgebung aufzusetzen und erhalten rund 1000 originalgetreue Testfragen zu den Prüfungen 70-270, 70-290, 70-291, 70-293, 70-294, 70-297 und 70-284. Darüber hinaus vermittelt der Autor zu den einzelnen Themengebieten praktisches Fachwissen, welches auch über die Prüfung hinaus nützlich ist.

• Titel: MCSE für Windows Server 2003
• Autor: Thomas Joos
• Erscheinungsdatum: 11.12.2006
• Preisinfo: EUR 2,99
• Format: PDF (gezippt)

Den Downloadlink findet ihr unten in folgendem Beitrag.

Sollte jemanden dennoch etwas auffallen, der möge es mir bitte berichten.

Vielen Dank dafür!

Ich bitte dies zu entschuldigen und hoffe, dass alles schnell über die Bühne geht und meine Seite bald wieder erreichbar sein wird, sollte jemand von der Umstellung betroffen sein.

Vielen Dank für euer Verständnis.

Mein Szenario sieht wie folgt aus, dass ich bei Hetzner einen Rootserver habe mit fester IP natürlich, die ich für das Plesk Panel sowie die Hauptseite nutzen möchte und zusätzlich ein 8er Subnetz, welches ich für alle anderen Domains nutze.

Nun war mein Problem, dass ich nicht genau wusste, wie ich das Ganze angehen sollte, denn Plesk ist mir immer wieder ein Rätsel und ich wollte es eigentlich ohne Firewall und IPtables Einstellungen lösen, wobei es mit IPtables wohl auch gehen würde.

Den Lösungsweg habe ich meinem Freund Nils aka darookee zu verdanken, der mich tatkräftig dabei unterstützt hat.

Achtung: Alle hier gezeigten Änderungen geschehen auf eigene Gefahr und ich übernehme keine Haftung, falls der Server danach nicht mehr funktionieren sollte.

Lösungsweg

• per SSH auf den Linux Server gehen
• sich als “root” anmelden
• in das Verzeichnis /etc/sw-cp-server/applications.d/ gehen
• die Datei plesk.conf bearbeiten
• alle $SERVER["socket"] == “IP:8443″ mit der Haupt-IP und dem Plesk-Port 8443 ändern
• mit “:wq” die plesk.conf speichern und schließen
• danach den SWsoft Control Panel Server mit “/etc/init.d/sw-cp-server restart” neustarten

Getestet wurde dieser Lösungsweg mit einem 64-Bit Debian 4.0 und Plesk 9.2.1.

Es ist vielleicht keine schöne Lösung und es ist zu prüfen, ob nach einem Update die plesk.conf wieder bearbeitet werden muss, doch bei mir funktioniert es und damit bin ich zufrieden.

Für Anregungen und andere Lösungswege bin ich offen. Danke Nils!

Aus diversen Foren konnte man immer wieder den Tipp lesen, dass man den Backup Manager neu deinstallieren und dann neu installieren soll. Doch auch dies brachte mir nicht den gewünschten Erfolg.

Nach langer und vor allem erfolgloser Suche habe ich heute im Parallels Forum eine private Nachricht bekommen, in der ein MySQL-Dump der Tabelle “BackupsScheduled” beigefügt war.

– Tabellenstruktur für Tabelle `BackupsScheduled`
— Erzeugt am: 31. März 2009 um 14:35
DROP TABLE IF EXISTS `BackupsScheduled`;
CREATE TABLE IF NOT EXISTS `BackupsScheduled` (
`id` int(10) unsigned NOT NULL auto_increment,
`obj_id` int(10) unsigned NOT NULL,
`obj_type` enum(‘server’,'reseller’,'client’,'domain’) NOT NULL,
`repository` enum(‘local’,'ftp’) NOT NULL default ‘local’,
`last` datetime default NULL,
`period` int(10) unsigned NOT NULL,
`active` enum(‘true’,'false’) NOT NULL,
`processed` enum(‘true’,'false’) NOT NULL,
`rotation` int(11) NOT NULL default ’0′,
`prefix` varchar(255) character set utf8 default NULL,
`email` varchar(255) character set utf8 default NULL,
`split_size` int(10) unsigned NOT NULL default ’0′,
`suspend` enum(‘true’,'false’) NOT NULL default ‘false’,
`with_content` enum(‘true’,'false’) NOT NULL default ‘true’,
`backup_day` int(10) unsigned NOT NULL default ’0′,
`backup_time` time NOT NULL default ’00:00:00′,
PRIMARY KEY  (`id`)
) ENGINE=InnoDB  DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;

Download: Plesk 9.0.1 MySQL Table BackupsScheduled (253)

Ich war sehr glücklich und sicherte sofort die Datenbank und spielte die neue Tabelle ein und versuchte mein Glück.

Nach erfolgreichem Login in mein Plesk Panel ging es zielstrebig zum Backup Manager meiner Domain und ich versuchte eine geplantes Backup zu erstellen. Die Meldungen die sonst immer auftauchten, lauten wie folgt:

• Fehler: Informationen über geplantes Backup können nicht aktualisiert werden: MySQL query failed: Unknown column ‘backup_time’ in ‘field list’
• Fehler: Informationen über geplantes Backup können nicht aktualisiert werden: MySQL query failed: Unknown column ‘backup_day’ in ‘field list’
• Fehler: Informationen über geplantes Backup können nicht aktualisiert werden: MySQL query failed: Column ‘last’ cannot be null

Durch die Einspielung dieses MySQL-Dump kommt es endlich zur erfolgreichen Erstellung der geplanten Backups und Pleskt gibt nur noch folgende Meldung aus.

• Informationen: Backup von Domain big2k.net wurde geplant.

Falls jemand von euch das selbe Problem hat, dann kann ich nur empfehlen, dass der MySQL-Dump in eure Datenbank hinzugefügt wird.

Bei mir funktioniert es nun wunderbar und ich sage vielen Dank Herr K.

Ich bitte dies zu entschuldigen und hoffe, dass alles schnell über die Bühne geht und meine Seite bald wieder ohne Probleme erreichbar ist.

Vielen Dank für euer Verständnis.

Sollte jemanden etwas auffallen, was merkwürdig erscheint, bitte kurz bescheid geben. Danke!

Die Wartungsarbeiten sind für den 17. März 2009 in einem Zeitraum von voraussichtlich 01.00 – 07.00 Uhr vorgesehen. Wer also als Nachtschwärmer Probleme hat auf meine Seite zu kommen, den möchte ich bitten es später noch einmal zu versuchen.

Zwar dürfte laut Hetzner durch die redundante Auslegung aller Systeme kein Ausfall zu erwarten sein, dennoch kann es auf Grund des häufigen Umroutens des Traffics zu kurzen Verbindungsunterbrechungen kommen.

Ich bitte um Verständnis.

• Sat 1 Planetopia Bewerbung (329)
• Sat 1 Planetopia vom 5. September 2004 (DivX) (309)
• Sat 1 Planetopia vom 5. September 2004 (MPEG) (316)
• Sat 1 Planetopia vom 5. September 2004 (PDF) (395)