Moin Moin, richtiges Pinguinwetter :D
ich hab ein Problem. Auf meinem VServer läuft ein von der Console gestartetes PHP-script (CLI) das eine Zip (170mb) auspackt (ca 2000 bilder) und diese in ein Wordpress importiert ohne große Problme. Bei einem bekannten auf dessen Server (der dem beim Herrn Schlitterman gehört :D ) bricht das Script einfach ab. Der letzte Logeintrag liegt vor dem entZippen. Vermutlich passiert dann irgendetwas. Das Zip das der Bekannte verarbeitet ist etwas größer (400mb und entsprechend mehr Bilder). Der Speicherplatz reicht auf dem Server daran kanns nicht liegen. Aber gibt es Bedinungen bei denen ein PHP-CLI-CronJob vorzeitig aussteigt?
Gruß Robert
Robert sportfreund_robert@gmx.de wrote:
Moin Moin, richtiges Pinguinwetter :D
ich hab ein Problem. Auf meinem VServer läuft ein von der Console gestartetes PHP-script (CLI) das eine Zip (170mb) auspackt (ca 2000 bilder) und diese in ein Wordpress importiert ohne große Problme. Bei einem bekannten auf dessen Server (der dem beim Herrn Schlitterman gehört :D ) bricht das Script einfach ab. Der letzte Logeintrag liegt vor dem entZippen. Vermutlich passiert dann irgendetwas. Das Zip das der Bekannte verarbeitet ist etwas größer (400mb und entsprechend mehr Bilder). Der Speicherplatz reicht auf dem Server daran kanns nicht liegen. Aber gibt es Bedinungen bei denen ein PHP-CLI-CronJob vorzeitig aussteigt?
Der 'Klassiker' hier ist, daß via CRON Du ein anderes Environment hast als wenn Du in der Console eingeloggt bist, insbesondere hast Du nicht den $PATH zur Verfügung. Schau mal, was da an Programmaufrufen ist, und rufe alles mit absoluten, also kompletten Pfaden auf.
Andreas
Hi und Danke schonmal
Am 03.02.2012 13:03, schrieb Andreas Kretschmer:
Der 'Klassiker' hier ist, daß via CRON Du ein anderes Environment hast als wenn Du in der Console eingeloggt bist, insbesondere hast Du nicht den $PATH zur Verfügung. Schau mal, was da an Programmaufrufen ist, und rufe alles mit absoluten, also kompletten Pfaden auf. Andreas
Ich komme da leider nicht ran. Da ist noch ein ServiceCenter dazwischen :/ Aber die Pfade machen, glaub ich, keine Probleme, denn 69 von 200 Ordner werden richtig entpackt dann ist einfach Schluss. (sry den Punkt hatte ich beim OP noch vergessen anzuführen)
Gruß Robert
Robert sportfreund_robert@gmx.de (Fr 03 Feb 2012 12:54:09 CET):
Moin Moin, richtiges Pinguinwetter :D
ich hab ein Problem. Auf meinem VServer läuft ein von der Console gestartetes PHP-script (CLI) das eine Zip (170mb) auspackt (ca 2000 bilder) und diese in ein Wordpress importiert ohne große Problme. Bei einem bekannten auf dessen Server (der dem beim Herrn Schlitterman gehört :D ) bricht das Script einfach ab. Der letzte
Vielleicht nimmst Du mal mit dem Herrn Schlittermann Kontakt auf? Seine Adresse ist relativ einfach zu finden.
Am 03.02.2012 13:24, schrieb Heiko Schlittermann:
Vielleicht nimmst Du mal mit dem Herrn Schlittermann Kontakt auf? Seine Adresse ist relativ einfach zu finden.
Hi, ich wollte keinen kostenlosen support erschleichen oder so. Das ist eher ein Zufall das die Server bei euch sind. Aber wie gesagt da ist noch eine ServiceZentrale dazwischen, die mit dem Hoster arbeitet, ich hab damit nichts zu tun. Ich hab nur eine Zuarbeit für für einen Servicenehmer geleistet und soll jetzt dafür sorgen das die bei denen funktioniert. Und das oben geschilderte ist alles was ich von dem was schiefgeht weiß. Und komme ich persönlich nicht an das Gerät ran.
Grüße, Robert
Robert sportfreund_robert@gmx.de (Fr 03 Feb 2012 13:34:27 CET):
Am 03.02.2012 13:24, schrieb Heiko Schlittermann:
Vielleicht nimmst Du mal mit dem Herrn Schlittermann Kontakt auf? Seine Adresse ist relativ einfach zu finden.
Hi, ich wollte keinen kostenlosen support erschleichen oder so. Das ist eher ein Zufall das die Server bei euch sind. Aber wie gesagt da ist noch eine ServiceZentrale dazwischen, die mit dem Hoster arbeitet, ich hab damit nichts zu tun. Ich hab nur eine Zuarbeit für für einen Servicenehmer geleistet und soll jetzt dafür sorgen das die bei denen funktioniert. Und das oben geschilderte ist alles was ich von dem was schiefgeht weiß. Und komme ich persönlich nicht an das Gerät ran.
Das mit der Service-Zentrale mußt Du mir mal erklären.
Wenn es um den Kunden geht, an den ich denke, dann ist das ein Server, den wir direkt betreuuen und der hier in DD liegt in einem unserer Schränke.
Robert sportfreund_robert@gmx.de (Fr 03 Feb 2012 12:54:09 CET):
Moin Moin, richtiges Pinguinwetter :D
ich hab ein Problem. Auf meinem VServer läuft ein von der Console gestartetes PHP-script (CLI) das eine Zip (170mb) auspackt (ca 2000 bilder) und diese in ein Wordpress importiert ohne große Problme. Bei einem bekannten auf dessen Server (der dem beim Herrn Schlitterman gehört :D ) bricht das Script einfach ab. Der letzte Logeintrag liegt vor dem entZippen. Vermutlich passiert dann irgendetwas. Das Zip das der Bekannte verarbeitet ist etwas größer (400mb und entsprechend mehr Bilder). Der Speicherplatz reicht auf dem Server daran kanns nicht liegen. Aber gibt es Bedinungen bei denen ein PHP-CLI-CronJob vorzeitig aussteigt?
Du könntest natürlich auch den Script selber starten, über PHP und Dir die Fehlermeldung in ein Logfile schreiben lassen.
(Stichwort Umleitung der Ausgabekanäle in der Shell.)
Ich habe das mal für Dich gemacht und die Ausrede ist, daß in Zeile 338
338: fwrite($h,$zip->getFromIndex($i));
kein Speicher mehr alloziert werden kann.
PHP Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 263908 bytes) in…
Das würdest Du auch sehen, wenn Du in dem Shell-Script, der vom Cron aufgerufen wird und welcher seinerseits ja dann den erwähnten PHP-Script startet (warum eigentlich muß das so umständlich sein?), die Ausgabe der
php …
Zeile umleitest.
Und ich frage mich, warum man ein 400+MB-Zip-File importieren muß und ob man das nicht in kleineren machen kann. Muß das täglich passieren, dann würde ich mich natürlich noch mehr fragen, ob das technisch sinnvoll und notwendig ist, denn es ändert sich doch sicherlich nicht jeden Tag der komplette Datenbestand, oder?
Das Grundübel scheint hier eine vermutlich in unserer PHP.ini verankerte Einstellung zu sein, die die maximale RAM-Größe für den PHP-Prozess festlegt.
Interessanterweise scheint diese Größe aber von mir nicht festgelegt worden zu sein:
# su -s /bin/sh <KUNDE> -c 'php --ini --info' | grep memory_limit memory_limit => -1 => -1 suhosin.memory_limit => 0 => 0
Vielleicht macht Wordpress das irgendwo? Und in der Tat, wenn ich mir die Files von WP anschaue, dann finde ich auch etwas, was das Limit freundlicherweise auf 32MB setzt.
It's the pilot, not the aircraft.
Hallo Heiko,
und vielen Dank für Deine Mühe!!
Am 03.02.2012 13:51, schrieb Heiko Schlittermann:
Du könntest natürlich auch den Script selber starten, über PHP und Dir die Fehlermeldung in ein Logfile schreiben lassen.
(Stichwort Umleitung der Ausgabekanäle in der Shell.)
OK, von hinten in die Brust und so.. naja. Problem ist dabei das WP keine echte cronFunktion hat. Es startet nur etwas wenn es getriggert (via Seitenaufruf) wird.
Ich habe das mal für Dich gemacht und die Ausrede ist, daß in Zeile 338
338: fwrite($h,$zip->getFromIndex($i));
kein Speicher mehr alloziert werden kann.
PHP Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 263908 bytes) in…
Daran kann ich jetzt aber nichts machen, oder? Kackt doch die php-cli executable ab, oder?
Das würdest Du auch sehen, wenn Du in dem Shell-Script, der vom Cron aufgerufen wird und welcher seinerseits ja dann den erwähnten PHP-Script startet (warum eigentlich muß das so umständlich sein?), die Ausgabe der
php …Zeile umleitest.
Ich logge ja meinerseits schon sehr viel aber was auf der Console passiert kann ich in php nicht mitscheiden. Glaube ich jedenfalls. Allerdings muss ich mirt mal Deine Version via php die console zu starten nochmal ansehen. Den php-befehl 'system' benutze ich ja schon zum schnellen löschen auf Dateiebene.
Und ich frage mich, warum man ein 400+MB-Zip-File importieren muß und ob man das nicht in kleineren machen kann. Muß das täglich passieren, dann würde ich mich natürlich noch mehr fragen, ob das technisch sinnvoll und notwendig ist, denn es ändert sich doch sicherlich nicht jeden Tag der komplette Datenbestand, oder?
Du, frage mich nicht. Das ist numal ein Großes Autohaus das mit noch größeren Autoherstellern bindende Verträge hat, und die wiederum sagen welcher Datenzulieferer das macht und der gibt das zeug numal so raus. Und die ZIPs werden sicher auch noch weiter wachsen. Und ich muss auch leider jeden Morgen den kompletten Bestand raus und wieder rein kippen.
Das Grundübel scheint hier eine vermutlich in unserer PHP.ini verankerte Einstellung zu sein, die die maximale RAM-Größe für den PHP-Prozess festlegt.
Interessanterweise scheint diese Größe aber von mir nicht festgelegt worden zu sein:
# su -s /bin/sh<KUNDE> -c 'php --ini --info' | grep memory_limit memory_limit => -1 => -1 suhosin.memory_limit => 0 => 0
Vielleicht macht Wordpress das irgendwo? Und in der Tat, wenn ich mir die Files von WP anschaue, dann finde ich auch etwas, was das Limit freundlicherweise auf 32MB setzt.
klingt komisch, da eine 200mb große zip durchaus gelesen wurde. Könnt ihr die php.ini anpassen?
Vielen Dank und lg Robert
PS: das mit dem Service ist so.. Ein Freund von mir baut Wordpressinstanzen. Er fand ein bekanntes Autohaus als Kunden. Der Kunde kümmert sich selber um seine IT. Bzw. das macht ein Sup der aber von Tuten und Blasen keine Ahnung hat (O-Ton: "äähmm.. wie kron?? Kann ich ihnen nicht einfach das root pw zuschicken ich kann mit diesem Serverkram nichts anfangen") Und die wiederrum arbeiten mit euch zusammen. Und ich kleiner Idiot hab meinem Freund mal ein kleines WP plugin gebaut. Das am Anfnag noch völlig anders funktioniert hat. *thats it*
Robert sportfreund_robert@gmx.de (Fr 03 Feb 2012 15:32:26 CET):
(Stichwort Umleitung der Ausgabekanäle in der Shell.)
OK, von hinten in die Brust und so.. naja. Problem ist dabei das WP keine echte cronFunktion hat. Es startet nur etwas wenn es getriggert (via Seitenaufruf) wird.
Nun, dafür gibt es ja Cron.
Ich habe das mal für Dich gemacht und die Ausrede ist, daß in Zeile 338 338: fwrite($h,$zip->getFromIndex($i)); kein Speicher mehr alloziert werden kann. PHP Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 263908 bytes) in…
Daran kann ich jetzt aber nichts machen, oder? Kackt doch die php-cli executable ab, oder?
Ja. Man kann das Limit hochsetzen oder ZIP-Files mit weniger Index (weniger Files?) haben.
Ich logge ja meinerseits schon sehr viel aber was auf der Console passiert kann ich in php nicht mitscheiden. Glaube ich jedenfalls. Allerdings muss ich mirt mal Deine Version via php die console zu starten nochmal ansehen. Den php-befehl 'system' benutze ich ja schon zum schnellen löschen auf Dateiebene.
system("…/cronscript.sh >log 2>&1")
sollte es tun.
Und ich frage mich, warum man ein 400+MB-Zip-File importieren muß und ob man das nicht in kleineren machen kann. Muß das täglich passieren, dann
…
so raus. Und die ZIPs werden sicher auch noch weiter wachsen. Und ich muss auch leider jeden Morgen den kompletten Bestand raus und wieder rein kippen.
Nun, da gibt es bestimmt Optimierungspotential. Man könnte gucken, ob wirklich die Datenbank leer und dann wieder voll gemacht werden muss…
Aber das ist jetzt eine andere Baustelle.
Das Grundübel scheint hier eine vermutlich in unserer PHP.ini verankerte Einstellung zu sein, die die maximale RAM-Größe für den PHP-Prozess festlegt.
Interessanterweise scheint diese Größe aber von mir nicht festgelegt worden zu sein:
…
Und in der Tat, wenn ich mir die Files von WP anschaue, dann finde ich auch etwas, was das Limit freundlicherweise auf 32MB setzt.
klingt komisch, da eine 200mb große zip durchaus gelesen wurde. Könnt ihr die php.ini anpassen?
Nein, in der PHP.ini schränken wir das nicht ein. Es gibt innerhalb des Wordpress mindestens eine Stelle, an der die Speichergeröße limitiert wird, die der laufende Prozess haben darf. Und dort fühle ich mich nicht zuständig. Ich könnte das natürlich machen, aber wahrscheinlich ist es nach dem nächsten Update von WP wieder futsch. Mit WP kenne ich micht aus und weiß auch so nicht, was der korrekte Weg wäre, damit das auch überlebt bei einem Update.
(O-Ton: "äähmm.. wie kron?? Kann ich ihnen nicht einfach das root pw zuschicken ich kann mit diesem Serverkram nichts anfangen") Und die
… dann ist das aber nicht auf einem Server von uns, das Root-PW kennt dort niemand.
lug-dd@mailman.schlittermann.de
-
Andreas Kretschmer -
Heiko Schlittermann -
Robert