staging.inyokaproject.org

Also der letzte Ausfall ist jetzt ja gut eine Woche her und aktuell gibt es keine Probleme mehr. Ich denke, daher scheint das Problem tatsächlich gelöst zu haben.

Danke nochmals an allen!

Nabend,

so also in der letzten Zeit ist dies wieder mehrmals passiert. Ich glaube aber, dass ich einen Nenner gefunden habe ☺

Jedesmal wenn in der nginx/error.log

1

2017/08/24 14:26:01 [error] 4534#4534: *119028 upstream timed out (110: Connection timed out) while reading response header from upstream, ...

ging immer folgendes voraus

1

2017/08/24 14:24:09 [error] 4534#4534: *119024 access forbidden by rule, client: 106.51.24.144, server: www.domain.de, request: "POST /xmlrpc.php HTTP/1.1", host: "domain.de"

Tatsächlich sind von der letzten Zeile hier dann diverse oberhalb des 1. timed out und tatsächlich ist exakt immer das vorausgegangen. Im Grunde wäre mir eigentlich diese Domain sogar egal (also im Sinne von schlicht abschalten), aber wenn es eine andere Möglichkeit gibt, würde ich diese vorziehen. Die XML-RPC-Api wird auf dieser Domain schlicht nicht gebraucht und ist auch in der jeweiligen nginx-Conf mit

1

location ~ xmlrpc.php { deny all; }

eigentlich blockiert. Wird vielleicht dennoch der PHP-FPM Prozess gestartet?

Hast du mal mal versucht ob die Regel überhaupt greift?

Bei mir z.B ging sie zuerst nicht, bis ich festgestellt habe, dass sie oberhalb von: \.php$ sein muss.

jb-alvarado Ja die greift. Erhalte ein 403 Forbidden von Nginx.

Das Problem ist leider nicht gelöst. Wieder jetzt das gleiche, diesmal sogar extremer, teilweise mehrmals täglich, dass das Problem auftaucht

1

[05-Sep-2017 06:58:05] WARNING: [pool www] server reached pm.max_children setting (100), consider raising it

Aktuelle Einstellungen (/etc/php/7.0/fpm/pool.d/www.conf):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

[www]
user = www-data
group = www-data
listen.owner = www-data
listen.group = www-data
pm = dynamic
pm.max_children = 100
pm.start_servers = 50
pm.min_spare_servers = 50
pm.max_spare_servers = 100
pm.process_idle_timeout = 10s;
php_admin_value[memory_limit] = 128M

Selbst wenn ich die childrens mit start_servers, min_spare_servers und max_spare_servers halbiere, ändert sich da nichts, außer dass vielleicht dann mal meist nur früh morgens der fpm-prozess hängt.

Das kanns doch echt nicht sein? Was läuft da denn schief? Ist ja nicht so, als hätte ich da auf den Domains mega traffic (komme pro Tag nicht mal auf 100 Uniques bei allen Domains!).

Da fällt mir leider auch nicht mehr soviel ein. Hast du mal kontrolliert, welche php Dateien gerade im Zugriff sind, wenn das passiert?

Damit die anderen Domains wenigstens noch erreichbar sind, könntest du für jede Domain eine extra www.conf anlegen. Dennoch sollte man natürlich herausfinden, warum es zu der hohen Belastung kommt.

Genau das versuche ich eigentlich schon die ganze zeit, leider finde ich da gar nichts heraus. Nur anhand der Timestamps aus den Nginx-Logs heraus ist keine eindeutige Domain ausfindig zu machen und welches PHP-Script das verursacht auch zumindest so nicht ersichtlich.

Kann man das generell nicht irgendwo mitloggen lassen, welches PHP-Script gerade dann zuletzt ausgeführt wurde?