From 62a5437d373efa237efbd8a43a7e095f5dd348e9 Mon Sep 17 00:00:00 2001 From: Joey Orlando Date: Thu, 24 Aug 2023 21:14:47 +0200 Subject: [PATCH] add comments to uwsgi config + tweak a few settings (#2856) --- engine/uwsgi.ini | 81 ++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 79 insertions(+), 2 deletions(-) diff --git a/engine/uwsgi.ini b/engine/uwsgi.ini index ab1fc170..2103d899 100644 --- a/engine/uwsgi.ini +++ b/engine/uwsgi.ini @@ -1,23 +1,100 @@ +; good resources for uwsgi configuration +; https://www.bloomberg.com/company/stories/configuring-uwsgi-production-deployment/ +; https://uwsgi-docs.readthedocs.io/en/latest/ThingsToKnow.html + [uwsgi] +; fail to start if any parameter in the configuration file isn’t explicitly understood by uWSGI strict=true + +; This parameter prevents uWSGI from starting if it is unable to find or load your application module. Without this +; option, uWSGI will ignore any syntax and import errors thrown at startup and will start an empty shell that will return +; 500s for all requests. This is especially problematic because monitoring systems may observe that uWSGI started +; successfully and think the application is available to service requests when, in fact, it is not. +; +; uWSGI continues to start without your application loaded because it thinks you may load an application dynamically +; later. This is the default behavior because the dynamic loading of apps used to be common. +need-app=true + chdir=/etc/app module=engine.wsgi:application + +; The master uWSGI process is necessary to gracefully re-spawn and pre-fork workers, consolidate logs, and manage many +; other features (shared memory, cron jobs, worker timeouts…). Without this feature on, uWSGI is a mere shadow of its +; true self. +; +; This option should always be set to ‘on’ unless you are using the more complex “emperor” system for multi-app +; deployments or are debugging specific behavior for which you want uWSGI to be limited. master=True + pidfile=/tmp/project-master.pid http=0.0.0.0:8080 processes=5 -harakiri=620 -max-requests=5000 + +; A feature of uWSGI that aborts workers that are serving requests for an excessively long time. Configured using the +; harakiri family of options. Every request that will take longer than the seconds specified in the harakiri timeout +; will be dropped and the corresponding worker recycled. +harakiri=60 ; seconds +harakiri-verbose=true + +; Worker Recycling +; Worker recycling can prevent issues that become apparent over time such as memory leaks or unintentional states. In +; some circumstances, however, it can improve performance because newer processes have fresh memory space. +; +; uWSGI provides multiple methods for recycling workers. Assuming your app is relatively quick to reload, all three of +; the methods below should be effectively harmless and provide protection against different failure scenarios. +max-requests=5000 ; Restart workers after this many requests +max-worker-lifetime=3600 ; Restart workers after this many seconds +reload-on-rss=2048 ; Restart workers after this much resident memory +worker-reload-mercy=60 ; How long to wait before forcefully killing workers + +; This option will instruct uWSGI to clean up any temporary files or UNIX sockets it created, such as HTTP sockets, +; pidfiles, or admin FIFOs. +; +; Leaving these files around can pose a problem under some circumstances, such as if a developer runs uWSGI as their +; own user, and takes ownership of these files. If the production user doesn’t have permission to delete those files, +; uWSGI may fail to function properly. vacuum=True + buffer-size=65535 http-auto-chunked=True http-timeout=620 post-buffering=1 + +; uWSGI disables Python threads by default, as described in the Things to Know doc. +; +; By default the Python plugin does not initialize the GIL. This means your app-generated threads will not run. If you +; need threads, remember to enable them with enable-threads. Running uWSGI in multithreading mode (with the threads +; options) will automatically enable threading support. This “strange” default behaviour is for performance reasons, no +; shame in that. +; +; This is another option that might be the right choice for you. If it is, great! You’ll see a minor speed-up, but +; chances are high that you’ll be using a background thread for something. Without this parameter set, those threads +; won’t execute and some developer will be stuck in a weird place until they “discover” this feature. It’s best to +; leave it ‘on’ by default and remove it on a case-by-case basis. enable-threads=true ; drop requests with CONTENT_LENGTH bigger than 15MB route-if=ishigher:${CONTENT_LENGTH};15000000 break:413 Request Entity Too Large +; Till uWSGI 2.1, by default, sending the SIGTERM signal to uWSGI means “brutally reload the stack” while the +; convention is to shut an application down on SIGTERM. To shutdown uWSGI, use SIGINT or SIGQUIT instead. If you +; absolutely can not live with uWSGI being so disrespectful towards SIGTERM, by all means, enable the die-on-term +; option. Fortunately, this bad choice has been fixed in uWSGI 2.1 + +; You should enable this feature because it makes uWSGI behave in the way that any sane developer would expect. Without +; it, kill, or any tool that sends SIGTERM (such as some system monitoring tools) would attempt to kill uWSGI without +; success, confounding the operator of said tools. +die-on-term=true + +; By default, uWSGI starts in multiple interpreter mode, which allows multiple services to be hosted in each worker +; process. +; +; Multiple interpreters are cool, but there are reports on some c extensions that do not cooperate well with them. +; +; When multiple interpreters are enabled, uWSGI will change the whole ThreadState (an internal Python structure) at +; every request. It is not so slow, but with some kind of app/extensions that could be overkill. +single-interpreter=true + logger=stdio log-format=source=engine:uwsgi status=%(status) method=%(method) path=%(uri) latency=%(secs) google_trace_id=%(var.HTTP_X_CLOUD_TRACE_CONTEXT) protocol=%(proto) resp_size=%(size) req_body_size=%(cl) log-encoder=format ${strftime:%%Y-%%m-%%d %%H:%%M:%%S} ${msgnl}