KeyHelp Community

STOP - Bitte lesen Sie die folgenden Hinweise aufmerksam durch!

1) Bitte füllen Sie die unten stehende Beitragsvorlage vollständig und gewissenhaft aus.
2) Die Mitglieder dieses Forums investieren ihre wertvolle Zeit, um zu helfen. Bitte stellen Sie im Gegenzug so viele Informationen wie möglich zur Verfügung und beschreiben Sie den Fehler möglichst präzise. Beiträge, die geringe Eigeninitiative zeigen, werden wahrscheinlich keine guten Antworten erhalten.

Wir behalten uns vor, Themen zu schließen, wenn die Vorlage nicht oder nur unvollständig ausgefüllt wurde.

Sie können diesen oberen Teil der Beitragsvorlage entfernen.
Die folgende Beitragsvorlage darf jedoch in keinem Fall entfernt werden.
---------------------------------------------------------------------------


Ich bin sicher, dass die Ursache des Problems bei KeyHelp liegt
(Probleme ohne KeyHelp-Bezug gehören ins Offtopic-Forum)

Möglich, bin mir nicht sicher


Server-Betriebssystem + Version
(z.B. Ubuntu 20.04)

Ubuntu 24.04 (64-bit)


Eingesetzte Server-Virtualisierung-Technologie
(z.B. keine, OpenVZ, KVM, XEN, etc.)

KVM


KeyHelp-Version + Build-Nummer
(z.B. 22.0 - Build 2366)

25.2 (Build 3483)

Problembeschreibung / Fehlermeldungen

- Seit einiger Zeit habe ich immer wieder Downtimes verschiedener Domain (aber hauptsächlich von einer Domain " the-greenleaf.in ", von Zeit zu Zeit sind es auch mal andere Domains aber hauptsächlich die genannte).
- Die Domains werden bei mir von Cloudflare verwaltet aber nur DNS-Only, es wird nichts durch den Proxy geführt (DNS ist in Keyhelp für die Domains deaktiviert).
- Email-Services und Server ansich ist in der Zeit eigentlich online.
- Leider konnte ich der betroffenen Zeit kein DIG machen, da es immer ist wenn ich gerade nicht vorm PC sitze.
- In den access und error logs der Domain konnte ich nichts merkwürdiges finden.
- Die Downtime ist oftmals nur 3-10 Minuten, dann läuft alles normal weiter (Monitoring von Hetrix und 4 Locations zeigen dann die Downtime).
- Ich habe jetzt bei meiner Hoster angeordnet die VM mal auf einen anderen Host zu verschieben.

Ich kann mir nur vorstellen dass es endweder am DNS von Cloudflare liegt, die VM zu sehr belastet ist oder irgendein Problem mit dem Webserver bzw. mit der einzelnen V-Host Domain. Ich kann leider nirgendwo was finden und weiss auch nicht wo ich weiter suchen sollte

Ist aber jedenfalls merkwürdig da es nur sporadisch ist und die letzten paar Tage vermehrt.

Erwartetes Ergebnis
Keine Timeouts

Tatsächliches Ergebnis
-

Schritte zur Reproduktion
-

Zusätzliche Informationen
(z.B. kürzlich durchgeführte Änderungen am Server, Auszüge aus Protokolldateien (/var/log/*, /var/log/keyhelp/php-error.log, etc.))

Änderungen an Domain, Konfiguration oder Sonstiges wurden nicht durchgeführt.

Wieviel Ram und CPU Cores hat die VM?
Die Seite läuft zwar, ist aber gefühlt einfach nur lahm.
Wenn dann alle 8000 User gleichzeitig online sind ist einfach ruck zuck, Schicht im Schacht.
Was zeigt der Apache Server Status und wie ist die Auslastung von CPU und Ram?
Gibt es SWAP?

- CPU-Kerne 8 @ 2,45 GHz
- CPU-Auslastung 2,50 % ( 0,20 0,19 0,18 )
- Arbeitsspeicher Frei: 11,57 GiB Belegt: 3,68 GiB Gesamt: 15,25 GiB

Lahm kann ich jetzt nicht wirklich feststellen (Cloud liegt in USA), darum gehts auch gar nicht (hat sich auch niemand darüber beschwert), es geht mir um die Downtimes die erst seit geräumiger Zeit sind.

SWAP hab ich jedenfalls nie manuell erstellt und wie es scheint ist es auch nicht notwendig bei meinem RAM-Verbrauch

Hier Apache Server Status Screenshot:

Ich bekomme das auch ab und an bei Hetrix gemeldet.

Jedoch stellt sich dann heraus wenn die Meldung kommt, dass die Seite(n) einwandfrei erreichbar sind... auch von den Locations die von Hetrix angemeckert werden.

Die Seite(n) die bei mir immer wieder mal fuer einen 10 Minuetigen Zeitraum down sind, sind sehr aktive und hoch frequentierte Seiten die auch vom Eigentuemer selbst ueberwacht werden. Der stellt in diesen, von Hetrix, genannten Zeitrauemen auch keine Downtime fest.

Ich vermute hier einen Glitch bei Hetrix, denn die selben Seiten ueberwache ich auch ueber UptimeRobot (von, meist, den selben Standorten) und da kommt es zu keiner Downtime Meldung.

Evtl. hilft Dir das die Meldung(en) besser einzustufen.

Könnte nicht auch der Cloudflare Proxy Infos liefern? Vielleicht mal probeweise einschalten.

Bei mir ist das leider nicht der Fall, wenn Hetrix das meldet, kann ich auch nicht auf die Seite. Andere Seiten auf dem gleichen Host funktionieren jedoch einwandfrei (oftmals).

Cloudflare ist DNS-Only und soll auch so bleiben

Merkwürdig, oder der Host beim grossen "H" ist wieder total überbucht :/ Hab da angefragt die VM mal zu verschieben, bisher aber keine Rückmeldung bekommen.

omexlu wrote: ↑Wed 12. Nov 2025, 10:14 Bei mir ist das leider nicht der Fall, wenn Hetrix das meldet, kann ich auch nicht auf die Seite. Andere Seiten auf dem gleichen Host funktionieren jedoch einwandfrei (oftmals).

Dann wuerde ich mal anfangen saemtliche Logfiles der Domain zu analysieren... alles andere ist Kaffeesatz lesen.

Hab ich doch oben geschrieben dass ich die beiden Logfiles dieser betroffenen Domain für den betroffenen Zeitraum durchforstet habe, nix anormales zu finden!

Manchmal ist es nur die Domain, manchmal mehrere, aber hauptsächlich halt die :/

OK.
Vielleicht habe ich mich unklar ausgedrückt.
Gemeint ist natürlich die Auslastung von Ram und CPU kurz vor dem Shutdown, am Besten zusammen mit dem Apache Status Bericht.
hetrix kann mit dem hetrix-agent auch Ram / CPU / Festplatte überwachen.

Das von dir geschilderte Verhalten, insbesondere wenn andere Webseiten auf demselben Server zeitgleich erreichbar sind, deutet auf ungenügende Systemressourcen für den Foren-Benutzer-Account hin. Poste mal bitte deine PHP FPM Einstellungen für diesen User.

NACHTRAG:
Beim Apache Server Status ist besonders das Scoreboard interessant. Dort siehst du wieviele Verbindungen "on hold" sind.

omexlu wrote: ↑Wed 12. Nov 2025, 09:58 SWAP hab ich jedenfalls nie manuell erstellt und wie es scheint ist es auch nicht notwendig bei meinem RAM-Verbrauch

Das ist ein weit verbreiteter Irrglaube. Es reicht bereits eine einzige Ram-Auslastungsspitze und der OOM Killer killt irgend einen Prozess.
Gäbe es SWAP, kann das nicht passieren.

Die Auslastung kurz vor, während oder nachdem "Shutdown" konnte ich bisher nicht tracken, weil das immer zu Zeiten ist an dem ich gerade nicht am PC sitze und es so kurze Downs sind dass ich nicht dazu komme

Den Hetrix-Monitor zum installieren auf dem Server möchte ich nicht nutzen.

Infos zu PHP Einstellungen für das betroffene Account:

memory_limit: 256M
max_exectuion_time: 150
post_max_size: 101M
upload_max_fizesize: 100M

Infos zu PHP-FPM Einstellungen für das betroffene Account:

pm: ondemand
pm.max_children: 3
pm.max_requests: 0

Das läuft seit einem Jahr so ohne Probleme.

SWAP habe ich in 17 Jahren nicht gebraucht, soviele Traffic macht die Seite auch nicht

Scoreboard:

Sorry, habe ich, als ich die Antwort getippt habe nicht mehr im Kopf gehabt.

Was mir noch einfaellt:

Mal die PHP-FPM Einstellung des Benutzers checken... evtl. kommt es da zu einem Engpass.

Manchmal hängt ein einzelner vHost durch PHP-FPM oder mod_fcgi-Probleme.

Edit: Ups, da war Tobi schneller..

Hab alle gefragten Infos im letzten Post von mir geupdated

omexlu wrote: ↑Wed 12. Nov 2025, 10:33 pm.max_children: 3
pm.max_requests: 0

Das läuft seit einem Jahr so ohne Probleme.

SWAP habe ich in 17 Jahren nicht gebraucht, soviele Traffic macht die Seite auch nicht

max.children würde ich auf min. 10 setzen und bei max.requests würde ich eine 1000 setzen.
Hier vermute ich auch das Problem. 0 (Null = unbegrenzt) klingt zwar gut, ist es aber nicht. Bei schlecht programmierten Skripten kann ggf. das Skript dann endlos Ressourcen fressen. Besser ist immer ein genau definierter Wert nach welchem ein Neustart erfolgt. Dieser erfolgt so schnell, dass du ihn gar nicht bemerkst.

Zu deinen Argumenten „will ich nicht“ und „hab ich noch nie gebraucht“ kann ich nur festhalten, dass man mit dieser Einstellung keine Probleme löst sondern immer im gestern verbleibt.

Tobi wrote: ↑Wed 12. Nov 2025, 10:45 Zu deinen Argumenten „will ich nicht“ und „hab ich noch nie gebraucht“ kann ich nur festhalten, dass man mit dieser Einstellung keine Probleme löst sondern immer im gestern verbleibt.

Ist doch das beste, gerade wenn es um PHP geht, warum auf PHP7 oder 8 wenn 5 doch immer lief. Die Besucherzahlen und Skripte haben sich in den letzten 17 Jahren vermutlich auch nie geändert.