Wenn Sie den Parameter max_requests von gunicorn angeben, führt jeder Worker-Prozess den Prozess automatisch erneut aus, wenn er die Anzahl der Anfragen "max_requests" verarbeitet. Es wird gestartet. Dies vermeidet Speicherlecks und verhindert die Erschöpfung der Serverressourcen.
In Gunicorn werden Anforderungen fast gleichmäßig an jeden Arbeitsprozess verteilt, sodass es Fälle gibt, in denen alle Arbeitsprozesse gleichzeitig "max_requests" erreichen und neu starten. In diesem Fall gibt es keinen Mitarbeiter, der die Anfrage für einen Moment bearbeiten kann. Aus Sicht des Benutzers ist es daher möglich, dass "Oh, diese Site wurde plötzlich extrem schwer?"
Daher wurde ab Version 19.2 der Parameter max_requests_jitter hinzugefügt. Wenn Sie den Code der Klasse "Worker" lesen, wird "max_requests" wie folgt in "init" festgelegt. [^ 1]
jitter = randint(0, cfg.max_requests_jitter)
self.max_requests = cfg.max_requests + jitter or MAXSIZE
Das heißt, wenn Sie "max_requests_jitter" auf eine Ganzzahl größer als 0 setzen, wird für jeden Arbeitsprozess ein zufälliger Wert von 0 bis "max_requests_jitter" bis "max_requests" hinzugefügt. Dies führt dazu, dass die "max_requests" jedes Worker-Prozesses unterschiedliche Werte haben, was dazu führt, dass das Neustart-Timing unterschiedlich ist und die oben genannten Probleme vermieden werden.
Diese Funktion wurde von einem ehemaligen Reddit-Ingenieur alienth vorgeschlagen. Es scheint, dass der Code ursprünglich von Reddit verwendet wurde. https://github.com/benoitc/gunicorn/pull/862
Laut alienths Kommentar "verwenden wir derzeit einen max_requests von 500 und einen max_requests_jitter von 200, damit ein Neustart erfolgt." Es heißt "sind hoch randomisiert.". Wenn Sie also "max_requests = 500" setzen, ist es eine schöne Variation.
Recommended Posts