Um ehrlich zu sein, dachte ich, dass etwas nicht stimmt. Funktioniert Ihr uWSGI wirklich mit max-request-delta? Ich kannte und las den Artikel. Der Artikel hat mir jedoch nicht so gut gefallen, und in der offiziellen Dokumentation wird auch max-request-delta erwähnt, sodass ich dachte, dass dies möglicherweise nicht der Fall ist (entschuldigen Sie).
Webserver als Ersatz für Apache: uWSGI Performance Tuning Max-request-delta wird in dem Artikel mit mehr als 100 Likes hier vorgestellt, und Delta funktioniert, nicht wahr? Ich dachte.
Während des Auslastungstests trat jedoch ein Ereignis auf, bei dem max-request-delta nicht zu funktionieren schien.
max-requests: 30000
max-requests-delta: 3000 #Es muss 3000 gewesen sein
worker: 50
Wenn ich einen Lasttest mit 3h200rps mit solchen Einstellungen durchführte, trat jedes Mal nach etwa 2 Stunden ein Fehler auf.
Nur rund 1,5 Millionen Anfragen
The work of process 18 is done. Seeya!"
...
"worker 6 killed successfully (pid: 16)"
...
"Respawned uWSGI worker 6 (new pid: 263)"
...
Es gibt ein Protokoll, das sagt, und unmittelbar danach
uWSGI listen queue of socket \":9090\" (fd: 3) full !!! (101/100)
Wurde angezeigt, und zu diesem Zeitpunkt konnte ich nicht länger als 30 Sekunden auf die ALB-Integritätsprüfung antworten, und die Aufgabe wurde von der ALB gelöscht. (Entwickelt mit Flask + Nginx + Fargate-Konfiguration.)
1,500,000 / 200 / 60 = 125 Wenn Sie 200 U / min ausführen, wird der uWSGI-Prozess nach 125 Minuten auf einmal neu gestartet, und während dieser Zeit werden Anforderungen mit 200 U / s gesendet, sodass sich während dieser Zeit zu viele Anforderungen in der Warteschlange befinden.
uWSGI listen queue of socket \":9090\" (fd: 3) full !!! (101/100)
Beurteilt, dass die Fehlermeldung angezeigt wurde. Wenn max-request-delta nicht funktioniert, wird alles verbunden.
Ich frage mich, ob es so etwas gibt, obwohl es fest im Dokument steht. .. Die Existenz eines strengen Modus beim Denken kennen.
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
Ich habe es so eingestellt und versucht, "Docker-Compose Down & Docker-Compose Build & Docker-Compose Up-D".
Es wurde versucht, in den Container zu gelangen, um das uWSGI-Protokoll anzuzeigen.
❯ docker exec -it uwsgi-app bash
Error response from daemon: Container b951a8b21f946ad980aedc9792622b6d3c08a91e6aa095fa8fd5ebd3fbe56b8e is not running
？ Da es noch nicht gestartet wurde, sehen Sie sich das Protokoll des Containers an.
❯ docker logs -f uwsgi-app
[uWSGI] getting YAML configuration from /etc/uwsgi/uwsgi.yml
[strict-mode] unknown config directive: max-requests-delta
Es war ernst. Ich war geblendet von der Anzahl der Likes. .. .. Es wurde auch in das Dokument geschrieben. .. ..
Wieder heißt es, dass es seit 2.1 unterstützt wird. https://github.com/unbit/uwsgi/issues/1488
https://github.com/unbit/uwsgi/issues/2037 ↑ Ab Ausgabe Frage
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?
Antworten
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)
Es scheint, dass viele Leute auf Max-Requests-Delta gewartet haben, aber es scheint, dass es noch nicht offiziell unterstützt wird.
Wenn Sie den uWSGI-Prozess nicht ordnungsgemäß neu starten, tritt ein Speicherverlust auf. Soweit ich später feststellen kann, verbraucht der uWSGI-Prozess eine bestimmte Menge an CPU, auch wenn keine Last vorhanden ist, und basiert auf der CPU-Auslastungsrate. Es gab auch ein Problem, dass die automatische Skalierung etwas schwierig war, daher möchte ich den uWSGI-Prozess ordnungsgemäß neu starten.
Ich habe noch keine klare Antwort gegeben, aber ich denke, dies kann durch Festlegen der Anzahl der uWSGI-Prozesse, die dynamisch an die Betriebsrate der uWSGI-Prozesse angepasst werden sollen, behoben werden.
Anstatt die Anzahl der Prozesse in einem Container dynamisch zu erhöhen oder zu verringern, ist es der Meinung, dass es besser ist, ihn fest zu halten und die Anzahl der Container durch automatische ECS-Skalierung zu ändern, und ich denke, dass dies sicherlich der Fall ist, aber Es gibt auch ein Problem des Massenneustarts von Prozessen. .. Ich habe noch keine klare Antwort gefunden.
cheaper-algo: busyness
processes: 100 #Maximale Anzahl von Prozessen
cheaper: 10 #Mindestanzahl von Prozessen
cheaper-initial: 50 #Anzahl der Prozesse beim Start von uWSGI
cheaper-overload: 3 #Um die Anzahl der Prozesse anzupassen, wird die Prozessverfügbarkeit jedes Mal berechnet. Das Gerät ist Sekunden.
cheaper-step: 30 #Anzahl der Prozesse, die gleichzeitig erhöht werden sollen
cheaper-busyness-multiplier: 30 #Geben Sie an, wie viele Sekunden gewartet werden soll, bevor der Prozess reduziert wird
cheaper-busyness-min: 20 #Wenn die Auslastungsrate unter diesen Wert fällt, reduzieren Sie die Anzahl der Prozesse
cheaper-busyness-max: 70 #Wenn die Auslastungsrate diesen Wert überschreitet, erhöhen Sie die Anzahl der Prozesse
cheaper-busyness-backlog-alert: 16 #Erhöhen Sie dringende Prozesse, wenn wartende Anforderungen diesen Wert überschreiten
cheaper-busyness-backlog-step: 8 #Anzahl der zu erstellenden dringenden Prozesse
cheaper-busyness-penalty: 2
Durch dynamisches Erhöhen oder Verringern der Anzahl von Prozessen auf diese Weise kann verhindert werden, dass derselbe Prozess bis zu einem gewissen Grad im Speicher vorhanden ist. Daher denke ich, dass dies eine Lösung für das Problem sein kann. (Es scheint, dass "Max-Worker-Lifetime" zusammen damit verwendet werden kann, aber ich mache mir Sorgen, dass alle Prozesse gleichzeitig neu gestartet werden könnten.)
Es ist schwierig, solide Informationen über uWSGI zu finden, da die Erklärung im offiziellen Dokument nicht sehr vollständig ist, aber ich hoffe, dass Bloombergs Artikel gut geschrieben und hilfreich war. Bitte schauen Sie sich das an.
Configuring uWSGI for Production Deployment
Ich werde einen weiteren Belastungstest durchführen und ihn hinzufügen, wenn ich eine Antwort geben kann.
Als Lösung konnte ich es lösen, indem ich alle Einstellungen mit Argumenten festlegte, ohne die uWSGI-Einstellungsdatei zu verwenden.
CMD ["uwsgi", "--yaml", "uwsgi.yml", \
"--max-worker-lifetime", "`awk -v min=1800 -v max=5400 'BEGIN{srand(); print int(min+rand()*(max-min+1))}'`" ]
Durch zufälliges Übergeben einer Zahl von 1800 bis 5400 an "--max-worker-lifetime" als Befehlszeilenargument, ohne sie in die Konfigurationsdatei zu schreiben Das Intervall, in dem Prozesse neu gestartet werden, wird zufällig im Bereich von 30 bis 90 Minuten für jeden Container festgelegt, und der uWSGI-Prozess aller Fargate Task-Container wird auf einmal neu gestartet. Ich konnte das verhindern.
Dies sollte auch Ausfallzeiten vermeiden.