Pour être honnête, je pensais que quelque chose n'allait pas. Votre uWSGI fonctionne-t-il vraiment max-requests-delta? Je connaissais et lisais l'article. Cependant, je n'ai pas tellement aimé l'article, et la documentation officielle mentionne également max-requests-delta, alors j'ai pensé que ce n'était peut-être pas le cas (excusez-moi).
Serveur Web pour remplacer Apache: uWSGI Performance Tuning Max-requests-delta est introduit dans l'article avec plus de 100 likes ici, et delta fonctionne, n'est-ce pas? Je pensais.
Cependant, pendant le test de charge, un événement s'est produit dans lequel max-requests-delta ne semble pas fonctionner.
max-requests: 30000
max-requests-delta: 3000 #Ça devait être 3000
worker: 50
Lorsque j'ai effectué un test de charge avec 3h200rps avec de tels paramètres, une erreur s'est produite à chaque fois après environ 2 heures.
Environ 1,5 million de demandes
The work of process 18 is done. Seeya!"
...
"worker 6 killed successfully (pid: 16)"
...
"Respawned uWSGI worker 6 (new pid: 263)"
...
Il y a un journal disant, et immédiatement après cela
uWSGI listen queue of socket \":9090\" (fd: 3) full !!! (101/100)
A été affiché, et à ce moment-là, ALB n'a pas pu répondre à la vérification de l'état d'ALB pendant plus de 30 secondes, et la tâche a été abandonnée par ALB. (Développé avec la configuration Flask + Nginx + Fargate.)
1,500,000 / 200 / 60 = 125 Si vous exécutez 200rps, les processus uWSGI redémarreront tous en même temps après 125 minutes, et les demandes seront envoyées à 200rps pendant ce temps, il y aura donc trop de demandes dans la file d'attente pendant ce temps.
uWSGI listen queue of socket \":9090\" (fd: 3) full !!! (101/100)
Jugé que le message d'erreur était affiché. Si max-requests-delta ne fonctionne pas, tout sera connecté.
Je me demande s'il existe une telle chose même si elle est fermement inscrite dans le document. .. Connaître l'existence du mode strict en pensant.
This option tells uWSGI to fail to start if any parameter in the configuration file isn’t explicitly understood by uWSGI.
strict: true
max-requests: 3000
max-requests-delta: 300
Je l'ai défini comme ceci et j'ai essayé docker-compose down && docker-compose build && docker-compose up -d.
Essayer d'entrer dans le conteneur pour voir le journal uWSGI.
❯ docker exec -it uwsgi-app bash
Error response from daemon: Container b951a8b21f946ad980aedc9792622b6d3c08a91e6aa095fa8fd5ebd3fbe56b8e is not running
？ Puisqu'il n'a pas démarré, regardez le journal du conteneur.
❯ docker logs -f uwsgi-app
[uWSGI] getting YAML configuration from /etc/uwsgi/uwsgi.yml
[strict-mode] unknown config directive: max-requests-delta
C'était sérieux. J'ai été ébloui par le nombre de likes. .. .. C'était également écrit dans le document. .. ..
Encore une fois, il dit qu'il est pris en charge depuis la version 2.1. https://github.com/unbit/uwsgi/issues/1488
https://github.com/unbit/uwsgi/issues/2037 ↑ Du numéro Question
When will the new release be tagged? I'm waiting for the max-requests-delta option, and I'm reading things about the version 2.1 since 2017. Any news here?
répondre
Hi, unfortunately i do not think there will be a 'supported 2.1' any time soon. Currently the objective is to leave the 2.1 as the 'edge' branch and backport requested features to 2.0. This is completely a fault of mine, not having a proper test suite since the beginning caused a stall in 'commercially supportable' releases after 10 years. @xrmx is doing a great work in backporting. So back to gevent, has someone found the technical issue ? (sorry, maybe there is already a patch but i did not find it)
Il semble que beaucoup de gens aient attendu max-requests-delta, mais il semble qu'il ne sera pas encore officiellement pris en charge.
Si vous ne redémarrez pas correctement le processus uWSGI, une fuite de mémoire se produira, et pour autant que je puisse l'observer plus tard, le processus uWSGI utilisera une certaine quantité de CPU même en l'absence de charge, et elle sera basée sur le taux d'utilisation du CPU. Il y avait également un problème lié au fait que Auto Scaling était un peu difficile à faire, je souhaite donc redémarrer correctement le processus uWSGI.
Je n'ai pas encore de réponse claire, mais je pense que cela peut être géré en définissant le nombre de processus uWSGI à ajuster dynamiquement en fonction du taux de fonctionnement des processus uWSGI.
Plutôt que d'augmenter ou de diminuer dynamiquement le nombre de processus dans un conteneur, il est préférable de le maintenir fixe et de modifier le nombre de conteneurs par l'autoscaling ECS, et je pense que c'est certainement le cas, mais Il existe également un problème de redémarrage en masse des processus. .. Je n'ai pas encore trouvé de réponse claire.
cheaper-algo: busyness
processes: 100 #Nombre maximum de processus
cheaper: 10 #Nombre minimum de processus
cheaper-initial: 50 #Nombre de processus au démarrage de uWSGI
cheaper-overload: 3 #Pour ajuster le nombre de processus, le temps de disponibilité du processus est calculé à chaque fois. L'unité est la seconde.
cheaper-step: 30 #Nombre de processus à augmenter à la fois
cheaper-busyness-multiplier: 30 #Spécifiez le nombre de secondes à attendre avant de réduire le processus
cheaper-busyness-min: 20 #Si le taux d'utilisation tombe en dessous de cette valeur, réduisez le nombre de processus
cheaper-busyness-max: 70 #Si le taux d'utilisation dépasse cette valeur, augmentez le nombre de processus
cheaper-busyness-backlog-alert: 16 #Augmentez les processus urgents si les demandes en attente dépassent cette valeur
cheaper-busyness-backlog-step: 8 #Nombre de processus urgents à créer
cheaper-busyness-penalty: 2
En augmentant ou en diminuant dynamiquement le nombre de processus de cette manière, il est possible d'empêcher le même processus d'exister dans la mémoire dans une certaine mesure, donc je pense que cela peut être une solution au problème.
(Si vous combinez cela, vous pouvez utiliser max-worker-life, mais je crains que tous les processus puissent être redémarrés en même temps.)
Il est difficile de trouver des informations solides sur uWSGI car l'explication du document officiel n'est pas si complète, mais ce serait bien si l'article de Bloomberg était bien écrit et utile. Jetez un œil à ceci.
Configuring uWSGI for Production Deployment
Je vais faire un peu plus de test de charge et l'ajouter si je peux donner une réponse.
En guise de solution, j'ai pu le résoudre en définissant tous les paramètres avec des arguments sans utiliser le fichier de paramètres uWSGI.
CMD ["uwsgi", "--yaml", "uwsgi.yml", \
"--max-worker-lifetime", "`awk -v min=1800 -v max=5400 'BEGIN{srand(); print int(min+rand()*(max-min+1))}'`" ]
En passant aléatoirement un nombre de 1800 à 5400 à --max-worker-life comme argument de ligne de commande sans l'écrire dans le fichier de configuration
L'intervalle auquel les processus sont redémarrés est déterminé aléatoirement dans la plage de 30 à 90 minutes pour chaque conteneur, et le processus uWSGI de tous les conteneurs Fargate Task est redémarré en même temps. J'ai pu l'empêcher de se produire.
Cela devrait également éliminer tout temps d'arrêt.