4images Forum & Community
4images Issues / Ausgaben => Discussion & Troubleshooting => Topic started by: oelke on December 19, 2002, 09:19:03 PM
-
Ich benutze jetzt seit einigen Wochen 4Images und bin eigentlich sehr zufrieden damit. Zuvor habe ich Imagefolio eingesetzt.
In der letzten Zeit ist mir allerdings aufgefallen, daß auf meinem Dedicated Server Apache Prozesse hängen, die fast die gesamte CPU-Zeit verbrauchen und anscheinend solange aktiv bleiben, bis ich sie hart kille (der längste war mal ca. 8 Stunden aktiv).
Inzwischen haben sich ca. 700 User in meinem 4Images angemeldet und diese erzeugen auch gut Traffic (ca. 60 GB im Monat). Der Traffic war zuvor mit Imagefolio identisch, jedoch häufen sich die Apache Hänger jetzt immer mehr. Am Anfang nur einmal die Woche, dann einmal am Tag und jetzt muß ich teilweise Apache 2-3 Mal pro Stunde neu starten.
Ich habe alle möglichen Ursachen untersucht... den Speicher und die HD gecheckt, nach Hacker-Angriffen gesucht und bei den letzten beiden Hängern ist mir mit Hilfe der Apache-Status Anzeige aufgefallen, daß der Apache-Prozess jedesmal ein 4Images-Prozess war. Und zwar immer ein Zugriff auf detail.php.
Im Prinzip scheint der Prozess dann auch nicht wirklich zu hängen, aber sich in einer Art Endlosschleife zu befinden, da der Prozess rennt und rennt und die ganze CPU-Zeit dabei schluckt.
Es ist natürlich ausgesprochen schwierig, die Ursache hierfür herauszubekommen, aber möglicherweise haben die Entwickler von 4Images eine Idee, was in 4Images zu einer Endlosschleife führen könnte?
Man kann natürlich trotzdem noch nicht 100% wissen, ob wirklich 4Images die Ursache des Problems ist. Ich werde nun bei jedem weiteren Hänger checken, welcher Aufruf dafür verantwortlich war. Wenn es dann nach ca. 2 Wochen tatsächlich immer 4Images-Aufrufe waren, ist es wohl ziemlich sicher, daß es daran liegt (der Gesamttraffic auf meinem Server verteilt sich auf 25 Domains und insgesamt ca. 250 GB, so daß eigentlich nicht aus Zufall immer 4Images der aufrufende Prozess sein sollte).
Ist natürlich für meinen Server momentan ein schlimmer Zustand und ich hoffe ich kriege das irgendwie in den Griff auch MIT 4Images.
Gruß,
Andreas
-
Wie Du schon selbst gesagt hast, schwer zu sagen. Auf Anhieb fällt mir leider nichts dazu ein. Solltest Du wietere Anhaltspunkte finden, her damit...
Jan
-
Nach ein paar Tagen und etlichen weiteren Hängern, gehe ich jetzt immer sicherer davon aus, daß 4Images dafür verantwortlich ist.
Der hängende Prozeß wird immer entweder von details.php oder download.php ausgelöst.
Ich tippe mal, daß dann irgendwas in den includes (sessions.php oder global.php) dieses Verhalten verursacht.
Um ganz sicher zu gehen, würde ich 4Images gerne für ein paar Tage de-aktivieren, jedoch gibt es anscheinend keine einfache Methode (wie z.B. in einem Discussion Board) ein Flag auf disabled zu setzen, damit Benutzer eine Meldung bekommen, daß die Gallery zur Zeit nicht aktiviert ist.
Da ich von allen möglichen Stellen der Website auf 4Images verlinke und darauf zugreife, wäre es eine ziemliche Arbeit, dieses temporär zu ändern.
Gibt es irgendeinen Trick, wie ich eventuell die Sourcen an einer bestimmten Stelle ändern kann, um den Benutzern bei jedem Zugriff einfach nur eine Standardmeldung ("Gallery temporarily deactivated!") zu zeigen?
Für einen Tip in dieser Richtung wäre ich sehr dankbar!
Gruß,
Andreas
-
Das kannst Du in der Datei global.php machen, da alle Dateien darauf zugreifen. Einfach an den Anfang folgenden Code:
header("Location: disabled.html");
exit;Dann wird immer auf die Datei disabled.html weitergeleitet die Du dann auch schön gestalten kannst. Ansonsten ginge auch:
die("Galerie inaktiv");
Jan
-
Ok, danke für den Tip!
Nach eine Ergänzung zum oben geschriebenen. Die Hänger scheinen hauptsächlich bei Heavy Traffic vorzukommen.
Ich habe z.B. ein Video (ca. 30 MB lang) welches von ca. 40 Usern gleichzeitig downgeloadet wurde. Einer dieser Prozesse hing dann.
Der Rechner hat auf jeden Fall genug Performance und es handelt sich ja auch nur um einfache Downloads. Da sollte Apache trotzdem nicht auf 99.9% gehen. Außerdem kommt der Prozess ja auch nach Stunden nicht wieder.
Gibt es denn irgendeine Möglichkeit dem Problem auf die Spur zu kommen? Oder muß ich mich dann doch auf die Suche nach einer neuen Software machen?
Das wäre natürlich schade, da 4Images von den Features her einfach unschlagbar ist und PHP eigentlich auch von der Performance her viel unproblematischer als Perl-Skripts sind (deshalb bin ich ja auch von imagefolio weg).
Gruß,
Andreas
-
Evtl. könnte es an der Zip-Funktion liegen. Dabei muss die komplette Datei eingelesen werden. Vielleicht kommt es dabei zu Hängern.
Jan
-
äh.. kann man das Video nicht irgendwie stärker Komprimieren? Mit DivX z.B. :roll: dann wird es evtl. kleiner??? Und hängt deswegen nicht mehr?
-
äh.. kann man das Video nicht irgendwie stärker Komprimieren? Mit DivX z.B. :roll: dann wird es evtl. kleiner??? Und hängt deswegen nicht mehr?
Ich glaube nicht, daß es effektiv so sehr an der Größe liegt. Die Wahrscheinlichkeit ist dabei nur höher.
Außerdem sind die Videos bereits in DIVX und soweit komprimiert wie die Qualität noch ok ist.
Gruß,
Andreas
-
Evtl. könnte es an der Zip-Funktion liegen. Dabei muss die komplette Datei eingelesen werden. Vielleicht kommt es dabei zu Hängern.
Läßt sich die ZIP-Funktion irgendwie disablen?
Andreas
-
Was meinste mit Disablen? So, das man keine Videos mehr hochladen kann? Oder nicht mehr herunterladen kann? Oder beides?
-
Was meinste mit Disablen? So, das man keine Videos mehr hochladen kann? Oder nicht mehr herunterladen kann? Oder beides?
Nein, nur daß die Lightbox-Funktion oder die ZIP-Funktion der Lightbox disabled wird.
-
Hm...
wenn du aus deinen Templates den Befehl "{lightbox_button}" rausnimmst, dann haste keine Lightbox mehr...
-
Du kannst {download_zip_button} aus dem Template details.html entfernen.
Jan
-
Ok.
Noch eine Frage... wo werden eigentlich die temporär erzeugten ZIP-Files auf dem Server abgelegt? Ich kann da so auf Anhieb nichts finden und einen Pfad dafür stellt man ja auch nirgendwo ein.
Andreas
-
Ich würde sagen irgendwo in Date/Media schau mal nach!
-
So, nach gut 4 Tagen ohne ZIP-Funktion kann ich mit ziemlicher Sicherheit sagen, daß die Apache-Hänger darauf zurückzuführen sind!
Seitdem ich den ZIP-Button entfernt habe und den Download-Button der Lightbox, funktioniert alles problemlos.
Ich schätze mal, daß die ZIP-Funktionalität einfach nicht mit so großen Files umgehen kann. Es wird ja alles erstmal im Hauptspeicher in ein Array gepackt. Das funktioniert wahrscheinlich noch für Bilder, aber bei 30 MB Videos scheint sich das dann irgendwann abzuhängen... und wenn dann auch noch mehrere Videos in der Lightbox waren...
Wird die ZIP-Funktion dann für das nächste Update nochmal in dieser Hinsicht überarbeitet?
Ist ja recht schade, daß ich das jetzt nicht mehr nutzen kann, da es ja eine sehr praktische Funktion war. Außerdem hat die Lightbox jetzt natürlich nicht mehr sonderlich viel Sinn...
Gruß,
Andreas
-
Kommt da jetzt in nächster Zeit noch ein Update? Und wann kann man damit rechnen?
Andreas
-
Evtl. hilft Dir dieser Beitrag: http://www.4homepages.de/forum/viewtopic.php?t=1325
Jan
-
Danke, ich habe die entsprechende download.php installiert und werde mal beobachten wie es damit klappt.
Andreas
-
Das mit den ZIPs klappt jetzt prima und es gibt auch keine Server-Hänger mehr.
Allerdings ist durch diese neue download.php ein neues Problem entstanden.
Einige Files (bisher konnte ich es nur bei Videos mit einer Länge um die 30 MB beobachten) können beim Klick auf den Download-Button nicht mehr downgeloadet werden. Es kommt direkt eine Fehlerseite so als ob die Verbindung zum Server unterbrochen wurde.
Der ZIP-Download Button klappt und alle Downloads für Bilder oder andere Dateien klappen auch.
Ich bin jetzt nicht sicher, ob es an der Größe der Dateien oder am Typ (AVI, MPEG) liegt, aber auf jeden Fall funktioniert das mit der alten download.php!
Falls Ihr das selbst mal ausprobieren wollt, einfach mal hier registrieren:
http://www.theatreoftragedy.com/gallery/
und nach dem Einloggen in die music_videos category wechseln und versuchen z.B. das "Let you down" video downzuloaden (mit Klick auf den normalen Download-Button).
Wäre schon, wenn sich dieses Problem auch noch irgendwie fixen läßt.
Gruß,
Andreas
-
Das dürfte wieder daran liegen, dass die Datei zu gross ist. Probiere mal folgendes:
Ändere in download.php
if ($remote_url) {
header("Location: ".$file['file_path']);
exit;
}
zu
if ($remote_url || (filesize($file['file_path') / 1048576) > 30) {
header("Location: ".$file['file_path']);
exit;
}
Die 30 am Ende der if-Abfrage gibt die Größe in MB an. In diesem Fall wird bei allen Dateien die größer als 30 MB sind auf die Datei weitergeleitet. Da das in Deinem Fall wohl nur die Videos sind, müsste sich der "Speichern unter"-Dialog öffnen.
Jan
-
Nein, hat auch irgendwie nicht den gewünschten Effekt.
Dann bekommt man keinen "Speicher unter..." Dialog sondern das Video öffnet sich im Windows Media Player.
Außerdem erstellt er dann auch kein ZIP mehr wenn man den ZIP-Button klickt, sondern öffnet ebenfalls nur den Media-Player.
Wofür ist die Datei denn zu groß? Ist das eine Beschränkung in der php.ini?
Andreas
-
Ja sorry, die Änderung war Blödsinn :roll:
Wahrscheinlich musst Du "memory_limit" in der php.ini höher setzen.
Jan
-
Wahrscheinlich musst Du "memory_limit" in der php.ini höher setzen.
Hab ich schon getan, von 8 MB auf 40 MB... aber bis auf die Tatsache, daß dann der Speicherverbrauch bei den entsprechenden httpd prozessen extrem ansteigt und es etwas länger dauert, bis die Fehlermeldung kommt, hat es keine positive Wirkung gebracht.
Na ja, ich kann ja nochmal experimentieren, die Grenze noch höher zu setzen, wobei mir nicht ganz klar ist, wieso er für den Download soviel Hauptspeicher benötigt.
Andreas
-
Das Problem ist, dass für den Download die gesamte Datei eingelesen werden muss. Wie Du bei meiner letzten Änderung gesehen hast, wird bei direktem Verlinken auf eine Datei je nach Einstelllung im Browser die Datei direkt in einem Programm geöffnet ohne den "Speichern unter" Dialog. Um das zu verhindern, wird vor der Ausgabe der Datei eine Header-Information gesendet, sodass der Browser denkt, er hätte eine Datei vor sich, die er nicht zuordnen kann und öffnet den "Speichern unter"-Dialog.
Jan
-
Ich habe die download.php nochmal ein bischen verändert. Probiers mal mit dieser:
Download: download_oelke.zip (http://www.4homepages.de/forumdl/download_oelke.zip)
Jan
-
Cool, damit funktioniert es prima.
Danke!
Gruß,
Andreas
-
In dem Zusammenhang habe ich jetzt noch ein Problem festgestellt.
Wird eigentlich irgendwann der Inhalt des Download-Verzeichnisses gelöscht?
Ich habe gerade mal reingeschaut und es haben sich inzwischen über 3 GB an ZIP-files angesammelt.
Könnte man nicht noch was in die Routine einbauen, daß alle Files die länger als einen Tag alt sind, gelöscht werden?
Gruß,
Andreas
-
Das sollte normalerweise passieren. Teste mal ob die Dateien wirklich nicht gelöscht werden oder ob die Dateien noch von der älteren download.php stammen. (Die Dateien per Hand löschen und mal eine Datei herunterladen).
Jan
-
Nein, die werden wirklich nicht gelöscht und stammen auch nicht von einem Download mit der alten Version, da ich für jeden Tag etliche ZIP-Files und Verzeichnisse (mit den jeweiligen unkomprimierten Original-Files) dort liegen habe, seit ca. 21. Januar bis einschließlich heute.
Also wurde nichts mehr gelöscht, seit ich die neue Version der download.php eingespielt habe.
Gruß,
Andreas
-
Hmm..also bei mir funktionierts. Steht bei Dir am Ende der download.php folgender Teil?
if (isset($unlink_tmp_file)) {
unlink($unlink_tmp_file);
}
Jan
-
Ja, steht da...
Hmm, dann scheint er wohl irgendwie nicht bis dahin zu kommen.
Kann man irgendwelche debug-ausgaben einschalten, die eventuell nur im access.log zu sehen sind?
Oder wie kann man dem Problem sonst am besten auf die Schliche kommen?
-
Das kann schon sein, dass das Script vorher beendet wird, gerade bei grossen Dateien. Das Problem ist ja, dass die Datei zum Download angeboten werden und gleichzeitig schon gelöscht sein soll.
Probiere mal folgendes:
Füge
remove_tmp_folder(DOWNLOAD_TMP_PATH);
vor
$file = array();ein
Jan
-
Jetzt versteh ich gar nichts mehr.
Nachdem ich die Änderung eingebaut habe, bekam ich nur noch folgende Meldung beim Klick auf den ZIP-Button:
Fatal error: Call to undefined function: get_remote_file() in /home/virtual/site2/fst/var/www/html/gallery/download.php on line 66
Dann habe ich die Änderung zurückgenommen und immer noch der gleiche Fehler.
Danach habe ich die download.php nochmal upgeloadet so wie Du sie in das zip-file gepackt hattest und ich bekomme immer noch den gleichen Fehler.
Was ist denn jetzt kaputt gegangen?
-
Ach, ich weiß jetzt...
Das Einfügen dieser Zeile hat dazu geführt, daß er das gesamte download-Verzeichnis gelöscht hat und daher konnte er die Files nirgendwo mehr ablegen.
Ich habe das download-Verzeichnis wieder neu angelegt und jetzt ist es zumindest wieder so wie vorher.
Hat also nichts gebracht und die Files werden nach wie vor nicht gelöscht.
-
Ich habe jetzt mal selbst ein paar Zeilen an den Anfang des Skripts reingebastelt, wo alle Files im DOWNLOAD_TMP_PATH rekursiv gelöscht werden, wenn sie älter als 1 Tag sind.
Müßte eigentlich so funktionieren...
Gruß,
Andreas
-
Upps ja, sorry. War wohl noch etwas zu früh für mich :roll:
Gruß Jan