Lucrătorii Apache MPM blocați în G (terminând cu grație) în creștere - „tabloul de bord este plin”

Rulează MPM worker, Apache 2.4.46, Debian 9

Lucrătorii de finisare cu grație cresc în timp, nu par să termine vreodată. În cele din urmă, am rămas fără capacitate și primesc eroarea „tabloul de bord este plin”. Dacă repornesc apache, se eliberează.

Nu cred că are vreo legătură cu codul site-ului meu (php), deoarece multe dintre cererile suspendate sunt doar imagini pure GET, fără php implicat.

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

tablou de bord

exemplu g muncitori

apache peste săptămână, sloturile gratuite în scădere

încercat cu menținerea în viață intermitent și oprit

Când utilizați MPM worker, cererile sunt gestionate de firele de execuție care există în procese.

Din https://httpd.apache.org/docs/2.4/mod/worker.html

Un singur proces de control (părinte) este responsabil pentru lansarea proceselor copil. Fiecare proces copil creează un număr fix de fire de execuție de server, așa cum este specificat în directiva ThreadsPerChild, precum și un fir de execuție care ascultă conexiunile și le transmite unui fir de execuție de server pentru procesare atunci când ajung.

Pe Linux, un proces „conține” fire de execuție, adică un PID poate avea mai multe fire de execuție care partajează memoria (printre alte resurse) cu alte fire de execuție din acel PID.

De fapt, Linux îi pasă doar de „sarcini”, un proces fără mai multe fire este un PID cu un container de unu sarcină.

Când reîncărcați Apache cu grație, încheiați procesul de conținut. Ceea ce se întâmplă aici este că Apache face ca fiecare fir să aștepte până când toate firele din procesul care le conține, înainte de a reporni PID-ul containerului.

Deci, în cazul dvs., aveți un singur fir conținut în toate procesele din acea listă care este încă ocupat sau blocat cumva.

Ai câteva opțiuni.

1. Renunță oricum să mai aștepți și repornește.
2. Găsiți firul cu probleme (ar putea fi o eroare în aplicație) și remediați-l.

1, este ușor. Adăugați opțiunea de configurare GracefulShutdownTimeout cu o valoare mare dar nu stupidă. Spune 900 de secunde. În mod implicit, acesta este infinit, ceea ce înseamnă că firele dvs. așteaptă pentru totdeauna până când firul cu probleme să se termine.

Principalul dezavantaj al acestui lucru este că întâmpinați șansa de a lovi un proces în mijlocul unei activități critice -- care terminarea ar putea, la rândul său, să corupă un fișier sau să rupă subtil aplicația. Aveți, de asemenea, o șansă (disparabil de mică) de a rezilia un client la jumătatea procesării.

2, vă va implica să identificați firul care este blocat în lista de lucrători și apoi să diagnosticați ceea ce face conexiunea, dar veți găsi ceea ce ar putea fi un defect de design și puteți explica comportamentul cu mai multă încredere înainte de a sufla. îndepărtați un fir cu probleme.