Dans gunicorn (> = 19.2), utilisez max_requests_jitter avec max_requests

Que sont les max_requests?

Si vous spécifiez le paramètre max_requests de gunicorn, chaque processus de travail se réexécute automatiquement lorsqu'il traite les demandes pour les heures de max_requests. Il va démarrer. Cela évite les fuites de mémoire et empêche l'épuisement des ressources du serveur.

Quel est le problème avec max_requests seul?

Puisque gunicorn alloue les requêtes à chaque processus de travail presque uniformément, il existe des cas où tous les processus de travail atteignent max_requests et redémarrent en même temps. Dans ce cas, il n'y a pas de travailleur qui puisse gérer la demande pendant un moment, donc du point de vue de l'utilisateur, il est possible que "Oh, ce site est soudainement devenu extrêmement lourd?"

Nouvelles fonctionnalités de la version 19.2 max_requests_jitter

Par conséquent, à partir de la version 19.2, le paramètre max_requests_jitter a été ajouté. Si vous lisez le code de la classe Worker, max_requests est défini dans __init__ comme suit. [^ 1]

        jitter = randint(0, cfg.max_requests_jitter)
        self.max_requests = cfg.max_requests + jitter or MAXSIZE

Autrement dit, définir max_requests_jitter sur un entier supérieur à 0 ajoutera une valeur aléatoire de 0 à max_requests_jitter à max_requests pour chaque processus de travail. Cela fera que les max_requests de chaque processus de travail auront des valeurs différentes, et le moment du redémarrage sera différent pour éviter le problème ci-dessus.

Cette fonctionnalité a été proposée par un ancien ingénieur Reddit alienth. Il semble que le code ait été utilisé à l'origine par Reddit. https://github.com/benoitc/gunicorn/pull/862

Selon le commentaire d'alienth, "Pour le moment, nous utilisons un max_requests de 500 et un max_requests_jitter de 200 pour que le redémarrage redémarre" Il dit "sont hautement aléatoires". Donc, si vous définissez max_requests = 500`` max_requests_jitter = 200, ce sera une belle variation.