master = true 

#Start the main process to manage other processes. Other uwsgi processes are child processes of the master process. If the master process is killed, it is equivalent to restarting all uwsgi processes.

chdir = /web/www/mysite 
#Switch to the current directory before the app loads and specify the running directory

module = mysite.wsgi 
#Load a WSGI module, here load the mysite/wsgi.py module

py-autoreload=1  
#Monitor python module mtime to trigger overloading (only used during development)

lazy-apps=true  
#Load apps in every worker instead of master

socket = /test/myapp.sock 
#Specify the socket file, or you can specify it as 127.0.0.1:9000, so that the network socket will be monitored

processes = 2 #Start 2 worker processes and generate the specified number of workers/processes

workers = 4 #Start 4 workers

threads=4 #Start 4 threads

enable-threads=True #Enable multithreaded mode

buffer-size = 32768 #Set the internal buffer size used for uwsgi package parsing to 64k. The default is 4k.

daemonize = /var/log/myapp_uwsgi.log 
#Make the process run in the background and log to the specified log file or udp server

log-maxsize = 5000000 #Set the maximum log file size

disable-logging = true #Disable request logging

vacuum = true #Automatically deletes unix socket files and pid files when the server quits.

listen = 120 #Set the listening queue size of the socket (default: 100)

pidfile = /var/run/uwsgi.pid #Specify a pid file

enable-threads = true 
#Allow starting threads in embedded languages. This will allow you to generate a subthread in the app

reload-mercy = 8 
#Set the maximum number of seconds to wait for the end of a work subprocess during a smooth restart (not restarting until the received request is processed). This configuration will cause the smooth restart of the working sub-process, if the working process ends more than 8 seconds, it will be forcibly terminated (ignoring previous requests and ending directly)

max-requests = 5000 
#Set a maximum number of requests for each worker process. When the number of requests processed by a worker process reaches this value, the worker process will be recycled (restarted). You can use this option to silently fight memory leaks

limit-as = 256 
#Limit the amount of virtual memory used by each uWSGI process by using the POSIX/UNIX setrlimit() function. This configuration limits uWSGI processes to no more than 256M of virtual memory. If the virtual memory has reached 256M and continues to apply for virtual memory, the program will report a memory error. This http request will return a 500 error (when a memory error occurs, it may be that the memory usage is not set enough)

harakiri = 60 
#If a request takes longer than the harakiri timeout, the request will be dropped and the working process currently processing the request will be recycled (i.e. restarted)