aPollO

Schau mal hier, hier ist erklärt was das bedeutet https://www.php.net/manual/de/install.fpm.configuration.php Auf der ersten Website die @d00p verlinkt hat wird folgendes "empfohlen" Vielleicht probierst du das mal aus. Das soll dem verschwenden von RAM durch PHP entgegen wirken (genaueres was da passiert dem Link zu php.net entnehmen und/oderdem Link von @d00p). Ich persönlich halte 1 Minute vielleicht für etwas übertrieben aber das kommt sicher auf das spezifische Szenario drauf an.

Was hast du in deiner php-fpm.conf eingestellt? Speziell was emergency_restart_threshold emergency_restart_interval process_control_timeout angeht?

Die ersten beiden Websites kann ich auch wärmsten empfehlen, hab die auch kürzlich erst gelesen. Stehen einige nützliche Tipps drin. Aber Wunder darf man natürlich auch keine erwarten. Wieviel Aufrufe hast du denn so und was heißt "viel" RAM?

Ich hab es jetzt mal auf dynamic umgestellt und ein bisschen angepasst und mal schauen ob es jetzt wieder vorkommt. Kam ja vorher auch nur alle paar Tage mal vor, dass das hing. Auf static hatte ich es weil die Seite über 120.000 Aufrufe am Tag hat und entsprehend zur Rush Hour einiges los ist.

Ich werde das noch mal durchkalkulieren. Ich hatte mir dazu einiges durchgelesen unter anderem das hier https://www.kinamo.be/en/support/faq/determining-the-correct-number-of-child-processes-for-php-fpm-on-nginx War aber irgendwie noch nicht so aufschlussreich. Ich muss mir da wohl die Doku noch mal genauer zu gemüte führen. Ich hätte irgendwie erwartet, dass die Fehlermeldung etwas mehr Aussagekraft hat, sowas wie "no free process to dispatch" oder sowas Achja Wunschdenken halt. Hast du eime Empfehlung, gibts eine Faustformel oder ein Guide wonach du dich orientierst?

Ich hatte es vorher auf 60 Sekunden. Das hatte aber (subjektiv gefühlt) keinen Unterschied gemacht. Das Problem dass das ganze PHP zeitweise steht bestand trotzdem. Aber ich werds mal auf 2 Minuten setzen und beobachten. Finde es aber trotzdem komisch, selbst wenn 1 Skript lange läuft dürfte doch nicht alles hängen und nichts mehr reagieren für über 10 Minuten oder? Oder hab ich das ganze FPM Konzept irgendwie nicht verstanden.

Klar wieso soll es nicht reichen? Weißt du überhaupt wozu die sources.list da ist und was da drin steht? Man kann diese sources.list auch noch erweitern um contrib oder non-free. Keine Ahnung ob du da was draus brauchst. Ich glaube für Froxlor nicht unbedingt, aber kann ich dir jetzt nicht genau sagen. EIgentlich müsste es reichen. https://wiki.debian.org/SourcesList Wenn du keine weiteren Paketquellen brauchst ausser die Standardquellen für das System+Sicherheitsupdates dann reicht das aus. Es empfiehlt sich vielleicht ein schnelleren lokalen Mirror zu wählen, aber das ist jetzt kein muss. Aber solange du davon keine Idee hast was das überhaupt macht, solltest du dich damit erstmal damit vergnügen zu lesen was APT ist und wie APT funktioniert und welche Rolle dabei die Sources-list hat. Sonst schreib ich mir hier die Finger Wund um dir die absoluten Basics zu erklären. Ich hab da generell nichts dagegen aber ich glaube das sprengt hier den Rahmen. Vielleicht auch eine Frage, wieso eigentlich Jessie? Wieso nicht Stretch? Jessie wird nur noch knapp über 1 Jahr supported, bis zum 30 Juni 2020. Danach gibt es dafür keine Updates mehr! PHP5 wird übrigens von den Debian Leuten auch noch bis dahin unterstützt auch wenn der php.net Support für PHP5 schon beendet ist. Wenn es dir um PHP5 geht, das kann man über externe Paketquellen auch unter Debian 9 installieren, wenn man es UNBEDINGT braucht. Aber wenn man es heute noch braucht bekommt eh bald ein Problem. Und wenn dir das alles egal ist, wie du geschrieben hast, "hauptsache es läuft", dann wird dein Server ganz schnell sicher eine schöne Spam-Schleuder oder deine Datenbanken landen irgendwo im Internet, samt Passwörter und Co.

1GB RAM should be enough for every variant. If you need more (free) memory you should maybe take a look at nginx?

Du schriebst vorher sie wäre "blanco". Das Wort "blanco" habe ich gegoogelt und es heißt "weiß" oder "blank". Also das NICHTS drin steht. Jetzt schrebst du es steht etwas drin. Ist das jetzt das was du im Moment da drin stehen hast oder das was ein hypotetischer anderer Kunde mit neuem Clud Server da drin stehen hat? Generell ist das alles was man da drin braucht. Genial wie du meinen Tippfehler mit kopierst, ausführst und es nicht merkt obwohl grep sogar so freundlich ist es in die Fehlermeldung zu schreiben....ich glaube erstmal solltest du noch mal einen Grundlagenkurs für Linux machen (YouTube oder ein Buch kaufen oder an einem Seminar teilnehmen, oder eigeninteresse). Viel Ahnung scheinst du ja nicht zu haben, denn wie man grep bedient ist eigentlich schon sehr basic. Ok wie dem auch sei. Leider hilft das recht wenig weiter, denn das mit dem grep hat ja nicht funktioniert, da am ende das -e zu viel war (ja war mein Fehler du hast es offenbar stumpf kopiert ohne zu gucken was du da machst). 370 Pakete sieht mir etwas wenig aus. Ich habe eigentlich überall über 500 aufwärts. Daher vermute ich das bei deiner Installation einiges fehlt. Es ergibt für mich irgendwie 0 Sinn wieso z.B. dovecot angeblich installiert ist aber es unter /etc/ kein dovecot Verzeichnis gibt. Entweder hast du es gelöscht oder ich hab keinen Plan wieso es nicht vorhanden ist. Und hier: Sicher, dass das Verzeichnis für Froxlor GENAU SO heißt? Also /var/www/html/Froxlor/ .......und nicht zufällig /var/www/html/froxlor/ ??? Ich hab leider keine Glaskugel mehr, die ist mit kaputt gegangen. Aber mein Menschenverstand sagt mir, du hast bestimmt das f klein geschrieben und nicht groß oder? Daher schau mal nach ob da vielleicht die Groß/Kleinschreibung nicht passt. Ich würde dir aber generell fast raten den Server entweder noch mal neu zu installieren oder zumindest mit Froxlor und seinen Diensten noch mal neu anzufangen. Weil fehlende Verzeichnisse in /etc/ sind jetzt nicht schwer zu fixen, aber es sind doch ein paar mehr komplexe Handlungen nötig als irgendwas aus diesem Forum zu copy&pasten. Eigentlich würds ja sogar schon geschrieben wie es geht.

Lieber Community, erstmal vorweg. Ja ich weiß das ist kein Froxlor Problem an sich. Allerdings habe ich das Problem im Zusammenhang mit Froxlor und hier sind ja auch einige wirklich schlaue und belesene Leute dabei. Vielleicht ist also Jemand im Stande mich auf die richtige Fährte zu schicken. Ich habe seit einiger Zeit (seitdem ich Debian mit allem drum und dran neu installiert habe und dann eine bestehende Froxlor-Installation mit allen Kunden darauf migriert habe) das Problem, dass offenbar das PHP-FPM "hängt". Das ganze wirkt sich dann so aus, dass ich folgende Logzeilen im Error-Log des Kunden habe: [Fri Mar 29 17:04:50.504543 2019] [proxy_fcgi:error] [pid 17024:tid 140393488283392] (70007)The timeout specified has expired: [client AA.BB.CC.DD:58255] AH01075: Error dispatching request to : (polling), referer: https://www.example.com/asdkjaksldad [Fri Mar 29 17:04:53.952288 2019] [proxy_fcgi:error] [pid 16827:tid 140393648056064] (70007)The timeout specified has expired: [client AA.BB.CC.DD:58256] AH01075: Error dispatching request to : (polling), referer: https://www.example.com/asdkjaksldad [Fri Mar 29 17:04:55.194137 2019] [proxy_fcgi:error] [pid 17024:tid 140393479890688] (70007)The timeout specified has expired: [client AA.BB.CC.DD:58258] AH01075: Error dispatching request to : (polling), referer: https://www.example.com/asdkjaksldad [Fri Mar 29 17:04:55.318287 2019] [proxy_fcgi:error] [pid 16892:tid 140393673234176] (70007)The timeout specified has expired: [client 11.22.33.44:1036] AH01075: Error dispatching request to : (polling) [Fri Mar 29 17:04:55.690728 2019] [proxy_fcgi:error] [pid 16893:tid 140392590722816] (70007)The timeout specified has expired: [client AA.BB.CC.DD:58257] AH01075: Error dispatching request to : (polling), referer: https://www.example.com/asdkjaksldad [Fri Mar 29 17:04:56.543343 2019] [proxy_fcgi:error] [pid 16827:tid 140393639663360] (70007)The timeout specified has expired: [client AA.BB.CC.DD:58259] AH01075: Error dispatching request to : (polling), referer: https://www.example.com/asdkjaksldad [Fri Mar 29 17:04:58.008471 2019] [proxy_fcgi:error] [pid 17024:tid 140393471497984] (70007)The timeout specified has expired: [client 12.23.34.45:48424] AH01075: Error dispatching request to : (polling) [Fri Mar 29 17:05:05.428688 2019] [proxy_fcgi:error] [pid 17024:tid 140393446319872] (70007)The timeout specified has expired: [client 10.20.30.40:32936] AH01075: Error dispatching request to : (polling) [Fri Mar 29 17:05:10.010339 2019] [proxy_fcgi:error] [pid 16827:tid 140393530246912] (70007)The timeout specified has expired: [client AA.BB.CC.DD:58261] AH01075: Error dispatching request to : (polling), referer: https://www.example.com/asdkjaksldad [Fri Mar 29 17:05:11.481955 2019] [proxy_fcgi:error] [pid 17024:tid 140393437927168] (70007)The timeout specified has expired: [client AA.BB.CC.DD:58262] AH01075: Error dispatching request to : (polling), referer: https://www.example.com/asdkjaksldad [Fri Mar 29 17:05:12.720592 2019] [proxy_fcgi:error] [pid 16827:tid 140393521854208] (70007)The timeout specified has expired: [client AA.BB.CC.DD:58264] AH01075: Error dispatching request to : (polling), referer: https://www.example.com/asdkjaksldad [Fri Mar 29 17:05:16.349631 2019] [proxy_fcgi:error] [pid 17024:tid 140393681626880] (70007)The timeout specified has expired: [client AA.BB.CC.DD:58265] AH01075: Error dispatching request to : (polling), referer: https://www.example.com/asdkjaksldad Im Browser ist dann nur noch folgendes zu sehen: Leider betrifft dies dann alle Kunden welche die selbe PHP-Version nutzen. Ich habe schon ein wenig im access Log gesucht was der Auslöser dafür sein könnte, aber so richtig etwas auffälliges gefunden. Ich vermute es kommt vor wenn ein PHP Script hängt oder wenn zu viele parallele Aufrufe stattfinden. Derzeit ist das PHP so konfiguriert Ich hab jetzt die anderen Websites erstmal so "gerettet" indem ich eigentlich nichts mehr mit Version 7.0 laufen lasse sonden auf 7.1, 7.2 und 7.3 umgestellt habe. Ich weiß es gibt einige Dokumente die davon sprechen wie man am besten berechnet welche Werte an ein Optimum herankommen sollen. Allerdings hab ich da noch nichts guts gefunden, vielleicht hat Jemand einen Tipp? Könnte es sein, dass es einfach zu wenig Prozesse sind? Jede Menge Aufrufe rennen ins Timeout. Kann ich rausbekommen wieso? Was hängt da oder antwortet ewig nicht? Nach ca. 10-15 Minuten funktioniert dann meistens auf ein mal wieder alles reibungslos und schnell als wäre nie etwas gewesen. Die Fehlermeldungen im Error-Log verschwinden dann. Im Moment wäre ich über jede Hilfe dankbar, ich belese mich aber auch paralell weiter.

Mach doch mal bitte auch eine apache2ctl -t Ergibt jedenfalls wenig Sinn das systemctl sagt der Apache2 läuft nicht und kann nicht starten aber über das init.d Skript geht es. Denn das init.d Skript sollte auch nur auf systemctl verweisen bzw. stellt nur eine abwärtskompatibilität dar. Irgendwas ist da vermurkst!

Bist du weiter gekommen mit deinem Problem? Ich hab mir das auch mal angesehen und sollte sich um ein ganz normales Debian 8 handeln. Wenn das nicht so ist würde ich wie empfohlen mal neu installieren. GGf. wäre noch folgendes interessant: uname -a cat /etc/issue cat /etc/apt/sources.list ls -la /etc/apt/sources.list.d/ ls -la /var/www/ dpkg -l | grep -e dovecot -e nano -e php -e postfix -e dpkg -l|wc -l

Ok ich bin schon ein wenig dämlich, ich hab meine Konfiguration mit dem default überschrieben gehabt. Wenn man natürlich den PM auf static und 1 Prozess einstellt dann ist das ein wenig unperformant.... 😵 Manchmal sieht man den Wald vor lauter Bäumen nicht mehr.

Hallo, mein Problem hat nichts direkt mit Froxlor selbst zu tun. Allerdings mit den ganzen Komponenten die mit Froxlor zu tun haben. Vielleicht hat ja Jemand eine Idee oder Lust mir zu helfen. Ich hoffe es ist daher OK das ist das hier ins Forum schreibe. Ich habe meine Froxlor Installation endlich mal auf ein Debian 9 mit Apache 2.4 und PHP7.0-FPM umgezogen, zusätzliche habe ich von sury.org noch PHP-FPM in Version 5.6, 7.1, 7.2 und 7.3 nachinstalliert. Soweit so gut. An sich funktioniert auch fast alles. Ich kann schön über Froxlor die PHP Version wählen und so weiter. Nun hab ich einige Kunden mit Joomla CMS. Mein Problem ist nun, dass es manchmal (willkürlich?) einfach "hängt" und es ewig dauert bis der Server antortet (time to first byte). Man sieht dann die Anfrage auch gar nicht in den access logs. Es kommt mir so vor als ob sich alles staut und dann nach einer weile löst sich alles mit einmal auf und dann überflutet es die access logs. Die Uhrzeiten der Einträge sind auch teilweise total durcheinander. So hatte ich vorhin Einträge von 9:12 und dann hing es 2-3 Minuten lang und dann kamen auf einmal Einträge von 9:08 Uhr und sowas. Das verwundert mich auch irgendwie ziemlich. Wenn es dann hängt, dann reagiert keine der Seiten mit einer PHP Version mehr. Die Domains die eine andere PHP Version benutzen funktionieren allerdings weiter. Ich vermute daher irgendwie ein Problem mit PHP-FPM. Aber ich bin noch nicht dahinter gekommen. Es gibt keinerlei Logs bzw. ich habe in die access und error Logs geschaut und in die /var/log/phpX.X-fpm.log und nichts auffälliges gefunden. Ich vermute die Ursache bei einer bestimmten Website eines Kunden der besonders viel Load hat im Vergleich zu den anderen, denn wenn es bei ihm hängt, dann laden die Websites der anderen Kunden unter der PHP Version zwar auch nicht mehr, bei denen kommt dann aber direkt eine Weise Seite und der Browser beendet das laden, bei diesem Kunden aber lädt und lädt der Browser dann. Manchmal kommt die Website dann nach lange Zeit, manchmal kommt auch nur eine Meldung: Service Unavailable Als wenn das PHP-FPM einfach nicht reagiert. Ich hab die Website dieses Kunden auch schonmal zwischen den PHP Versionen verschoben und das Problem scheint mitzuwandern. Eigentlich brauche ich hier jedoch 7.0 oder 5.6 da es mit neueren PHP's noch nicht 100% kompatibel ist. Ich habe OPCache aktiviert für alle PHP Versionen aktiviert. das scheint auch zu werkeln. Hat Jemand eine Idee wie man das weiter debuggen kann? Und ja ich hab es vorher in einer Testumgebung getestet, aber offenbar hab ich den realen Userload unterschätzt und nicht richtig simuliert

Achso. Ich dachte, dass das eventuell mit dem Paket mit kommt. Naja hab ich wohl zu viel "gedacht" und zu wenig gewusst. Sehe aber auch kein Problem darin die 5-10 Minuten zu investieren. Ist ja nicht kompliziert oder sowas. ING hast du vielleicht Probleme bei der normalen Installation bei denen man dir helfen kann?