Probleme mit WordPress-Präsenz

[tab-kh]

Dann das Plugin Wordpress deaktivieren. Wenn dann keine Fehler mehr kommen, dann wissen wir woran es liegt . Kann aber nicht sein, wenn so viele Websites mit WP laufen. Millionen Fliegen können nicht irren.

Nee, im Ernst, sicher dass PHP-FPM passend eingestellt ist und genügend Worker zur Verfügung stehen? Habt ihr zu der Zeit als du die Probleme hattest irgend welche Last-Tests gemacht? Im Moment schaffe ich es nicht, einen 503-Fehler zu bekommen. Und ich habe sicher deutlich mehr als 5 Mal geklickt, auch schnell nacheinander. Oder läuft das TYPO3 vielleicht nebenher mit dem selben Pool?

[goldene-zeiten]

Auch Child-Theme kommt nicht in Frage. Ich habe nur eines. auch die 512M pro Prozess sollten ausreichen. Hatte in KeyHelp zwischenzeiltich mal auf 1024M gestellt. Aber das Problem würde dann weiter bestehen.

TYPO3 läuft im selben Pool, wenn der gleiche Benutzer gemeint ist .

pm = ondemand
pm.max_children = 10
pm.max_requests = 0

[tab-kh]

Also selber Benutzer und selbe PHP-Version?

[goldene-zeiten]

Ja. Die TYPO3-Instanzen laufen genau wie die WordPress-Instanz unter dem selben Benutzer und auch der selben über KeyHelp installierten PHP-Version 8.3. Während ich mit TYPO3 keine Probleme habe, habe ich aber leider diese 503er bei WordPress.

[tab-kh]

XML-RPC aktiv? Darüber kann man auch prima DDOS-Attacken starten, was ja bekanntermaßen zu 503er Fehlern führen kann. Und gebraucht wird es eigentlich wohl kaum noch dank der REST-API. Dafür spricht aus meiner Sicht, dass ich den Fehler vorhin nicht reproduzieren konnte, als du es probiert hast lief vielleicht eine Attacke. Dagegen spricht m.E., dass dann die parallel laufenden TYPO3-Installationen doch wohl auch darunter leiden sollten.
Eventuell läuft die Seite auch etwas lahm. Was war es gleich? Wordpress? Ohne Cache-Plugin womöglich? Wenn der Apache bei einem von PHP-FPM zu bearbeitenden Request zu lang auf die Antwort warten muss, läuft er in einen Timeout -> 503. So langsam erschien mir die Seite aber nicht zu sein.

[goldene-zeiten]

Es läuft WordFence darauf. Ebenso WP Super Cache. DDOS Angriffe müssten eigentlich abgewehrt werden. Da habe ich insbesondere bei WordPress ein größeres Auge wegen Sicherheitsproblemen drauf als bei TYPO3. Ich beobachte beide - aber WordPress noch kritischer...

Und XML-RPC ist nunmehr deaktivert...

[Fezzi]

Ich hatte mal ein aehnliches Problem....

Was bei mir geholfen hat war das aus tarieren der pm.max_requests ... diese also nicht auf 0 lassen (hatte ich vorher auch... und der Server hat ausreichend Ressourcen und wurde nicht ueberlastet) sondern sich antasten was am Besten funkt...

Der Wert 500 mit pm.max_children 10 hat dann fast zum verschwinden des 503 Fehlers gefuehrt...
Zusaetzlich habe ich dann auch noch die max_input_vars auf 15000 gesetzt und der Spuk war vorbei.

Evtl. hilft das bei der Fehlersuche... ich kann uebrigens Deine 503 Fehler von hier aus (Phuket/Thailand) auf Deiner Seite reproduzieren.

[goldene-zeiten]

Der Fehler tritt scheinbar jetzt seltener auf - aber er lässt sich bei dir dennoch noch reproduzieren?

Deine empfohlenen Einstellungen wären demnach:

pm = ondemand
pm.max_children = 10
pm.max_requests = 500
max_input_vars = 15000

Aber wie kann es sein, dass TYPO3 so bescheiden und das angeblich so einfache und pflegeleichte WordPress so hungrig nach Ressourcen ist?

LG nach Thailand

[Fezzi]

Tja, warum WP so Ressourcen hungrig ist kann ich Dir nicht sagen...

Soweit mir bekannt ist ist T3 jedenfalls performanter als WP.

Ich wuerde an Deiner Stelle jetzt mal noch ein wenig mit den pm.max_requests spielen und evtl. ein wenig mehr pm.max_children dann koennte der Spuk bald ein Ende haben.

Was die max_input_vars = damit zu tun haben ist mir auch en Raetsel, aber es hat das 503 Problem eines meiner Kunden geloest.

Die performantesten Seiten meiner Kunden laufen alle auf ModX... und sind sehr Ressourcen schonend.

Edit: Im Moment spielst Du offensichtlich mit Deiner Seite... denn sie ist nur mit WP Fehler zu erreichen wenn ueberhaupt...

[Ralph]

schau doch mal wie viele Anfragen da durchrattern und welche URL das Ziel ist ...

Code: Select all

tail -f /home/users/<user>/logs/<web>/access.log
tail -n 500 /home/users/<user>/logs/<web>/access.log

schau dir auch an ob es eine UA Kennung gibt z.b. von irgendwelchen Badbots, falls dies der Fall sein sollte via Fail2Ban einen eigenen UA Filter erstellen der diese und weitere UA Strings blockiert mit maxretry = 1

An der URL erkennst du auch das Ziel (Plugin oder Theme) was dann als Schwachstelle in Frage kommt.
Alle Plugins die nicht wirklich benötigt werden > deinstallieren (weg damit)
Alle anderen Plugins aktualisieren (auto update gibt es dabei auch)
Falls es ein Plugin ist was attackiert wird, einfach weg damit.

Vorher überlegen welche Third Party Plugins überhaupt installiert werden sollen (müssen) und mal schauen wo diese herkommen ... die meisten davon werden irgendwo in Asien auf die schnelle zusammengebastelt und entsprechen nicht unseren Sicherheits Standards, es gibt auch einige mit bereits integrierter Backdoor oder sonstigem Crap

[Jolinar]

Die Werte von memory_limit, max_execution_time, post_max_size und upload_max_filesize auch mal prüfen, ob die ausreichend dimensioniert sind.

[goldene-zeiten]

Tja, warum WP so Ressourcen hungrig ist kann ich Dir nicht sagen...

Soweit mir bekannt ist ist T3 jedenfalls performanter als WP.

Ich wuerde an Deiner Stelle jetzt mal noch ein wenig mit den pm.max_requests spielen und evtl. ein wenig mehr pm.max_children dann koennte der Spuk bald ein Ende haben.

Was die max_input_vars = damit zu tun haben ist mir auch en Raetsel, aber es hat das 503 Problem eines meiner Kunden geloest.

Die performantesten Seiten meiner Kunden laufen alle auf ModX... und sind sehr Ressourcen schonend.

Edit: Im Moment spielst Du offensichtlich mit Deiner Seite... denn sie ist nur mit WP Fehler zu erreichen wenn ueberhaupt...

Zum Spielen komme ich gar nicht - sie ist seit gestern in der Nacht offline. Warum aber, muss ich nun erst rausfinden. Viel Freude habe ich bisher nicht daran.

[goldene-zeiten]

Die Werte von memory_limit, max_execution_time, post_max_size und upload_max_filesize auch mal prüfen, ob die ausreichend dimensioniert sind.

Jetzt bin ich noch einmal testweise auf PHP 8.2 runter gegangen, weil das auch alles die originale Konfiguration ist ohne JIT etc. Frontend läuft, aber das Backend löst nun einen 503 aus. Ist doch zum hüpfen.

Extensions habe ich auf ein Minimum reduziert. Ich habe auch nur durchweg welche gewählt, die aktuell sind und einen großen Verbreitungsgrad haben.

[goldene-zeiten]

Noch etwas verrücktes: das Backend arbeitet nur in PHP 8.3, das Frontend stabil mit PHP 8.2. Alle Plug-Ins laufen angeblich mit PHP 5.6, 7.2 oder höher.

[Jolinar]

Noch etwas verrücktes: das Backend arbeitet nur in PHP 8.3, das Frontend stabil mit PHP 8.2. Alle Plug-Ins laufen angeblich mit PHP 5.6, 7.2 oder höher.

Auch auf die Gefahr hin, daß ich mich wiederhole...Ganz pragmatisch alle Drittsoftware außer dem WP Core abschalten und dann Schritt für Schritt und Plugin für Plugin den Störenfried finden.
Du bekämpfst derzeit die Symptome der Störung, aber nicht die Störung selbst...

BTW:
Ohja, Ich sagte es wirklich schon einmal:

Alle Plugins deaktivieren, dann ein Plugin nach dem anderen wieder aktivieren und schauen, wann der Fehler auftritt...