nächstes »

[ChrisT]

Hallo,

ich kämpfe hier schon seit einigen Stunden mit der Migration von PG auf JG unter Joomla 1.0.15. Die PG, die etwa 9000 Bilder in knapp 100 Kategorien umfasst, funktioniert einwandfrei, allerdings meckert der Hoster wegen zu hoher DB-Last, deshalb Migration. Vor der Migration habe ich das das memory_limit und die max_execution_time hochgesetzt, temporär auf 100M & 900s, trotzdem bekomme ich nach etwa 2 Minuten einen 500er Servererror, und keinen Reload des Browsers (verschiedene getestet). Das Migrations-Logfile endet recht abrupt mit einer letzten Erfolgsmeldung, und das Server-Log spuckt zum 500er leider nichts aus. Es werden lediglich etwa 2200 Bilder rübergeschubst, bevor er aussteigt. Die Datei- und Verzeichnisrechte stimmen, PHP5 läuft als CGI, MySQL ist 4.x. Ich nutze die aktuellste JG-Version für 1.0.15, das Dateidatum des Migrations-Scripts

Code:

$Id: admin.migratep2j.class.php 1019 2009-01-11 12:07:33Z aha $

Hat jemand ähnliche Erfahrungen, oder besser noch, einen Trick? Die Bilder würde ich noch mit einem einfachen SQL-Query in die neue Tabelle wuppen können, aber bei den Kategorien haperts, alleine schon durch die neuen Pfade / Verzeichnisse.

Und noch ein Verbesserungsvorschlag:

Es wäre gut, wenn nach mißlungenem Migrieren die Einträge in der DB und die Bilder in der PG erhalten blieben, bei Shared Webspace ohne SSH-Zugang lädt man sich per FTP einen Wolf (n meinem Fall dann mal eben 6500 Bilder ), um die Ausgangssituation wiederherzustellen. Vielleicht kann man die Verzeichnisse und die DB auf Knopfdruck leeren / löschen, nachdem die Migration nach Test funktioniert hat.

Danke für jede Hilfe!

[mab]

Hi ChrisT,

es ist nicht notwendig, vor der Migration an den PHP-Einstellungen zu drehen, da das Migrations-Script diese berücksichtigt und die Migration entsprechend "abstottert".
Der Fehler (der 500er Servererror) hat auch nichts mit den PHP-Einstellungen zu tun, sondern wird direkt vom Server produziert.
In diesem FAQ versuche ich, diese Server-Fehlermeldungen zu erläutern (letztes Kapitel "Sonderfall 1und1").
Vielleicht solltest Du die PHP-Einstellungen wieder runtersetzen, damit der Server die Migration nicht abbricht...

[ChrisT]

Hallo mab,

ich habe diese Werte erst hochgeschraubt, nachdem es ohne diese Manipulation schon einen 500er gab. Ich bin es gewohnt, erst zu tüfteln, wenn es Probleme gibt, und ich bin auch nicht ganz unerfahren. Der Shared Webspace verfügt nominal über recht großzügige 50M memory_limit und 90s max_execution_time, deshalb hat mich das ja verwundert. Nach dem Hochsetzen wurden nach Wiederherstellen des Ausgangsstatus sogar mehr Bilder transferiert, als beim ersten Mal. Weiter wollte ich nicht gehen, um mir nicht Ärger mit dem Hoster einzuhandeln ;). Hm, da wird mir wohl nichts anderes übrig bleiben, als die Migration zu Fuß zu machen? Das Script ist ja super kommentiert, und anhand der Aktionen, die es schafft, bevor es abbricht, kann ich mir das schon irgendwie zusammenreimen, wie das alles zusammenpasst. Noch eine Möglichkeit wäre, die ganze Sache lokal zu versuchen, um sie dann auf den Webspace zu beamen.

Mich hat der 500er irritiert, weil die Umgebungsvariablen meiner Meinung nach okay sind. Übrigens nicht 1und1.

Thanks anyway.

[mab]

Hi ChrisT,

eigentlich müßte der 500er immer ungefähr an der gleichen Stelle kommen (wenn überhaupt); aber dazu müßte man wirklich wissen, was den Server überhaupt aussteigen lässt. Ein PHP-Problem kann es nicht sein, da sonst eine PHP-Fehlermeldung kommen würde. Die Datenbank schließe ich auch aus, da die sich ebenfalls melden würde, bevor der Server eine 500 rausdrückt.
Hast Du Zugang zu den Server-Logs? Du schreibst, die spucken nichts aus...
Normalerweise sollten 2000 - 3000 Bilder innerhalb weniger Sekunden migriert sein (siehe diese Erfolgsmeldungen).
 

[ChrisT]

Hi mab,

leider hatte ich keinen Zugang zu den Serverlogs, eher so etwas wie ein "Echtzeit-Fehlerlog", welches den Fehler dummerweise unterschlug. Bei meinem ersten Migrationsversuch hat er etwa 2200 Dateien migriert, nach insgesamt drei Minuten kam der 500er. Nach dem Hochschrauben der Werte machte er 2800, und stieg wieder aus. Mittlerweile denke ich, daß etwas an der Serverumgebung nicht stimmt.

Da auch meine Geduld begrenzt ist, habe ich das Szenario kurzerhand lokal nachgebaut, großzügig Speicher und Zeit vergeben, und nach 20 Minuten war es geschafft. Danach habe ich die Verzeichnisstruktur der JG inkl. Bilder per FTP auf den Webspace geschubst, und die entsprechenden DB-Tabellen kopiert. Erfolgreich. Der Hoster ist übrigens Domaingo, Tochter von Domainfactory.

Sei's drum, Auftrag erledigt, und dazugelernt. Das war sicher nicht die letzte Migration, ich hab die PG oft verbaut.

Danke für Deine Denkanstöße, und weiter so mit einer tollen Galerie-Extension .

[flotte]

...PHP5 läuft als CGI...

Wenn PHP als CGI läuft gibt es viele weitere Möglichkeiten warum ein Scriptabruch erfolgt und in einem Error 500 mündet. Aich abhängig davon welche CGI-Methode verwendet wird (fastcgi, fcgi, suphp...). Insbesondere bei ersten beiden gibt es eine Vielzahl weitrer Parameter die das Verhalten der Prozesse beinflussen. Die wenigen php.ini-Einstellungen sind nicht beliebig einstellbar, wenn in der Prozesssverwaltung andere Limits gelten.

[Claudia E.]

Ich erlaube mir einen Off-Topic-Post:
Herzlich willkommen an flotte!

[aHa]

..
Herzlich willkommen an flotte!

Dem schließe ich mich gerne an

Gruß
Andreas