Apache MPM-Worker stecken in G fest (werden ordnungsgemäß beendet) und wachsen – „Anzeigetafel ist voll“

Question

MPM-Worker wird ausgeführt, Apache 2.4.46, Debian 9

Die Anzahl der ordnungsgemäß fertigzustellenden Worker wächst mit der Zeit, sie scheinen nie fertig zu werden. Irgendwann ist meine Kapazität erschöpft und ich erhalte die Fehlermeldung „Scoreboard ist voll“. Wenn ich Apache neu starte, werden sie freigegeben.

Ich glaube nicht, dass es irgendetwas mit dem Code meiner Website (PHP) zu tun hat, da es sich bei vielen der hängenden Anfragen nur um reine Bild-GETs handelt und kein PHP beteiligt ist.

<IfModule mpm_worker_module>
ServerLimit 500
StartServers       10
MinSpareThreads    50
MaxSpareThreads    100
    ThreadLimit          64
    ThreadsPerChild      64
    MaxRequestWorkers     500
    MaxConnectionsPerChild   0
</IfModule>

Anzeigetafel

Beispiel g Arbeiter

Apache über Woche, freie Slots schwinden

habe es mit Keep Alive an und aus versucht

Answer 1

Wenn Sie MPM Worker verwenden, werden Anforderungen von Threads verarbeitet, die in Prozessen vorhanden sind.

Aushttps://httpd.apache.org/docs/2.4/mod/worker.html

Ein einzelner Steuerprozess (der übergeordnete Prozess) ist für das Starten untergeordneter Prozesse verantwortlich. Jeder untergeordnete Prozess erstellt eine feste Anzahl von Server-Threads, wie in der Anweisung ThreadsPerChild angegeben, sowie einen Listener-Thread, der auf Verbindungen wartet und diese bei Eintreffen zur Verarbeitung an einen Server-Thread weiterleitet.

Unter Linux „enthält“ ein Prozess Threads, d. h. ein PID kann mehrere Threads haben, die Speicher (neben anderen Ressourcen) mit anderen Threads in diesem PID gemeinsam nutzen.

Tatsächlich kümmert sich Linux nur um "Aufgaben", ein nicht-multithreaded-Prozess ist ein PID mit einem Container voneinsAufgabe.

Wenn Sie Apache ordnungsgemäß neu laden, beenden Sie den enthaltenen Prozess. Was hier passiert, ist, dass Apache jeden Thread warten lässt, bis alle Threads im enthaltenen Prozess abgeschlossen sind, bevor die Container-PID neu gestartet wird.

In Ihrem Fall gibt es in allen Prozessen dieser Liste einen einzelnen Thread, der immer noch beschäftigt ist oder irgendwie festhängt.

Sie haben einige Optionen.

1. Geben Sie das Warten einfach auf und starten Sie neu.
2. Suchen Sie den Problem-Thread (möglicherweise ein Fehler in der Anwendung) und beheben Sie ihn.

1 ist einfach. Fügen Sie die Konfigurationsoption GracefulShutdownTimeoutmit einem Wert hinzu, der hoch, aber nicht zu hoch ist. Sagen wir 900 Sekunden. Standardmäßig ist dies unendlich, was bedeutet, dass Ihre Threads ewig warten, bis Ihr Problem-Thread fertig ist.

Der größte Nachteil dabei ist, dass Sie möglicherweise einen Prozess mitten in einer kritischen Ausführung treffen, dessen Beendigung wiederum eine Datei beschädigen oder die Anwendung auf subtile Weise beschädigen kann. Außerdem besteht eine (verschwindend geringe) Wahrscheinlichkeit, dass ein Client mitten in der Verarbeitung beendet wird.

2 erfordert, dass Sie den Thread ausfindig machen, der in der Liste der Worker festhängt, und dann diagnostizieren, was die Verbindung macht. Sie werden aber mit Sicherheit einen möglichen Konstruktionsfehler finden und das Verhalten sicherer erklären können, bevor Sie einen Problem-Thread einfach wegblasen.