flask项目下的uwsgi配置方式及示例
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了flask项目下的uwsgi配置方式及示例相关的知识,希望对你有一定的参考价值。
参考技术A uwsgi通信接口配置的三种方式:三个方式看起来十分的相似,阅读了很多博客和官方文档,下面是自己的一些理解(可能不完全正确)!
图一是socket方式,现在大部分web服务器(如nginx)支持uwsgi, 这是这三种方式最高效的一种形式,socket通信速度会比http快
图二是http-socket方式,这个适用于web服务器不支持uwsgi时。
后面2个图都是http方式,但是这样会失去了nginx很多优秀的功能。
官方推荐的方式为socket以及http-socket方式,显然使用http方式会额外产生一个http进程,如果还通过nginx转发,那么效率上来说是相对比较低的。
linux3——flask+ubuntu+nginx+uwsgi
1.uwsgi配置
1.1配置文件
方式一:
[uwsgi]
# uwsgi 启动时所使用的地址与端口
socket = 127.0.0.1:8001
# 指向网站目录
chdir = /home/www/
# python 启动程序文件
wsgi-file = manage.py
# python 程序内用以启动的 application 变量名
callable = app
# 处理器数
processes = 4
# 线程数
threads = 2
#状态检测地址
stats = 127.0.0.1:9191
注意:callable=app 这个 app
是 manage.py 程序文件内的一个变量,这个变量的类型是 Flask的 application 类 。
方式二:
目录规划
(.env) [email protected]:~/web/flask/mysite$ tree .
.
├── hello.py
├── hello.pyc
├── uwsgi
│ ├── uwsgi.log # 日志文件,通过该文件查看uwsgi的日志
│ ├── uwsgi.pid # pid文件,通过该文件可以控制uwsgi的重启和停止
│ ├── uwsgi.sock # socket文件,配置nginx时候使用
│ └── uwsgi.status # status文件,可以查看uwsgi的运行状态
└── uwsgi.ini
配置使用
(.env) [email protected]:~/web/flask/mysite$ vi uwsgi.ini
[uwsgi]
chdir=/home/zhangshuaipeng/web/flask/mysite/
home=/home/zhangshuaipeng/web/flask/mysite/.env
module=hello # python文件的名称
callable=app
master=true
processes=2 # worker进程个数
chmod-socket=666
logfile-chmod=644
uid=zhangshuaipeng_web
gid=zhangshuaipeng_web
procname-prefix-spaced=mysite # uwsgi的进程名称前缀
py-autoreload=1 # py文件修改,自动加载
#http=0.0.0.0:8080 # 监听端口,测试时候使用
vacuum=true # 退出uwsgi是否清理中间文件,包含pid、sock和status文件
socket=%(chdir)/uwsgi/uwsgi.sock # socket文件,配置nginx时候使用stats=%(chdir)/uwsgi/uwsgi.status # status文件,可以查看uwsgi的运行状态
pidfile=%(chdir)/uwsgi/uwsgi.pid # pid文件,通过该文件可以控制uwsgi的重启和停止
daemonize=%(chdir)/uwsgi/uwsgi.log # 日志文件,通过该文件查看uwsgi的日志
常用命令
uwsgi --ini uwsgi.ini # 启动
uwsgi --reload uwsgi.pid # 重启
uwsgi --stop uwsgi.pid # 关闭
uwsgi的启动可以把参数加载命令行中,也可以是配置文件 .ini, .xml, .yaml 配置文件中,个人用的比较多得是 .ini 文件。
通过uwsgi --help可以查看得到:
-x|--xmlconfig load config from xml file
-x|--xml load config from xml file
--ini load config from ini file
-y|--yaml load config from yaml file
-y|--yml load config from yaml file
1.2安装
pip3 install uwsgi
2.nginx
2.1安装
sudo apt-get install nginx
2.2配置
注意三个文件的不同:这三个文件都在ext/nginx下
ext/nginx/sites-available/default
nginx.conf
/etc/nginx/conf.d
应用文件应该放在 /var/www/ 下,log 文件应该放到系统的 log 文件夹下等等,这个只是简单示例,更多配置内容,我们应该通过 uWSGI、Nginx 的文档学习。
方式一:Ubuntu 上配置 Nginx 也是很简单,不要去改动默认的 nginx.conf 只需要将/ext/nginx/sites-available/default文件替换掉就可以了。
新建一个 default 文件:
server {
listen 80;
server_name XXX.XXX.XXX; #公网地址
location / {
include uwsgi_params;
uwsgi_pass 127.0.0.1:8001; # 指向uwsgi 所应用的内部地址,所有请求将转发给uwsgi 处理
uwsgi_param UWSGI_PYHOME /home/www/my_flask/venv; # 指向虚拟环境目录
uwsgi_param UWSGI_CHDIR /home/www/my_flask; # 指向网站根目录
uwsgi_param UWSGI_SCRIPT manage:app; # 指定启动程序
}
}
更改配置还需要记得重启一下nginx:sudo service nginx restart
方式二:删掉 Nginx 的默认配置文件,在/etc/nginx/conf.d/中创建配置,实际上是创建软链
直接在当前目录下创建配置文件,将 Nginx 配置文件用软链接链接到 Nginx 配置文件夹中:
$ sudo rm /etc/nginx/sites-enabled/default
sudo ln -s /home/frank/Documents/helloflask/helloflask_nginx.conf /etc/nginx/conf.d/
下面给出一个简单的配置:
server {
listen 80;
server_name your.website.url
charset utf-8;
client_max_body_size 75M;
location / { try_files $uri @yourapplication; }
location @yourapplication {
include uwsgi_params;
uwsgi_pass unix:/home/frank/Documents/helloflask/helloflask_uwsgi.sock;
}
}
我们可以将上述内容保存为 helloflask_nginx.conf,稍作解释:server_name 可以是域名,也可以写 ip 地址,uwsgi_pass 是表明 Nginx 与 uwsgi 的交流方式,我这里用的是 sock 文件,当然你也可以用指定端口号的形式,具体可以看这里。
重启 Nginx:sudo /etc/init.d/nginx restart
方式三:在指定目录创建,编辑配置文件:/etc/nginx/conf.d/flask.conf,nginx 配置 新建文件 /etc/nginx/conf.d/xxx.conf xxx.conf 中xxx你来定
server { listen 81; server_name www.mysite.com; charset utf-8; client_max_body_size 5M; location /app1/ { include uwsgi_params; uwsgi_pass unix:/home/kevin/web/flask/mysite/uwsgi/uwsgi.sock; } location /static { alias /home/kevin/web/flask/mysite/static; } }
解释:
删除/etc/nginx/sites-enabled/ 以及 /etc/nginx/sites-available/ 下所有文件
你可以这么玩,sudo rm -f /etc/nginx/sites-enabled/default
为什么这么做呢?
先看nginx.conf里面有:
include /etc/nginx/conf.d/.conf;
include /etc/nginx/sites-enabled/;
而sites-enabled里面也有default这种文件,我这么做的原因是删了看着干净。以后做扩展找起来也好找,都在conf.d目录下。
2.3nginx启动测试
[email protected]:~/web/flask/mysite$ sudo service nginx start
[email protected]:~/web/flask/mysite$ ps -ef | grep nginx
root 2324 1 0 16:19 ? 00:00:00 nginx: master process /usr/sbin/nginx
www-data 2325 2324 0 16:19 ? 00:00:00 nginx: worker process
www-data 2326 2324 0 16:19 ? 00:00:00 nginx: worker process
www-data 2327 2324 0 16:19 ? 00:00:00 nginx: worker process
www-data 2328 2324 0 16:19 ? 00:00:00 nginx: worker process
zhangsh+ 2330 2171 0 16:20 pts/1 00:00:00 grep --color=auto nginx
3.服务测试
可以选用curl测试
- Http访问测试,一切OK
[email protected]:~$ curl http://192.168.1.32:81/app1/flask/
Hello World! Hello Flask!
[email protected]:~$ curl http://192.168.1.32:81/app1/
Hello World!
4.项目的上传
git方式
5.概念理解
- WSGI
- uWSGI
- uwsgi
- Nginx
浏览器发起请求,都是请求80端口
WSGI 是一种协议,不是任何包不是任何服务器,就和 TCP 协议一样。它定义了 Web 服务器和 Web 应用程序之前如何通信的规范。
至于为什么和 Python 扯在一起?因为这个协议是由 Python 在 2003 年提出的。(参考:PEP-333 和 PEP-3333 )
> WSGI is the Web Server Gateway Interface. It is a specification that describes how a web server communicates with web applications, and how web applications can be chained together to process one request.
uWSGI 是一个全功能的 HTTP 服务器,他要做的就是把 HTTP 协议转化成语言支持的网络协议。比如把 HTTP 协议转化成 WSGI 协议,让 Python 可以直接使用。
> The uWSGI project aims at developing a full stack for building hosting services.
>
> Application servers (for various programming languages and protocols), proxies, process managers and monitors are all implemented using a common api and a common configuration style.
uwsgi 是一种 uWSGI 的内部协议,使用二进制方式和其他应用程序进行通信。
> The uwsgi (lowercase!) protocol is the native protocol used by the uWSGI server.
>
> It is a binary protocol that can carry any type of data. The first 4 bytes of a uwsgi packet describe the type of the data contained by the packet.
Nginx 是一个 Web 服务器其中的 HTTP 服务器功能和 uWSGI 功能很类似,但是 Nginx 还可以用作更多用途,比如最常用的反向代理功能。
所以用一张图来描述一下这个过程:
uWSGI配合Nginx反向代理
很多框架和应用服务器都可以对静态文件的请求(如JavaScript、CSS、图片等)返回来自应用的响应,不过更好的做法是用反向代理服务器(比如Nginx)来处理此类请求,减轻应用服务器的负载,获得更好的性能。
随着应用扩大,可能会需要分布到不同的服务器(云主机)上,此类需求在早期可以用反向代理实现。
此外,Nginx的可扩展性(除了缓存之外,还有failover等其他机制)对于一些比较复杂的Web应用也很有帮助。
一个简单的服务器架构:
客户端请求 ----> Nginx (反向代理)
|
/|\
| | `-> App. Server I. 127.0.0.1:8081
| `--> App. Server II. 127.0.0.1:8082
`----> App. Server III. 127.0.0.1:8083
注:只监听127.0.0.1
的应用只能从本地访问,而如果设置成0.0.0.0
就能够从外部访问了。
flask,是一种python开发web的一种框架,类似的还有django,flask比较轻量,django适合大型项目。 flask框架写的web,通常可以直接运行起来就可以访问web了。但是这种方式只适合开发调试,前面已经提过。实际是它内部有一个web服务,叫wsgi。这个东西不是很全,只是作为部分被提供在flask框架内。生产环境中,需要另外的web服务来挂起flak写的网站。通常这个web服务就是uwsgi。稍后我们会讲到,怎么去安装配置uwsgi;
而对于nginx,它扮演的是反向代理角色。在大型项目里面常常扮演者反向代理和负载均衡的角色。 什么意思呢,就是用户发送的请求,全部通过这个nginx服务,nginx会去请求真正的内容服务器,也就是我们部署好的,uwsgi服务。uwsgi服务将用户需要的网页和数据,送到nginx服务那,再由nginx推送给用户。这个过程,对于用户来说,只和uwsgi服务发生关系。真正的内容服务器是不可见的。 所以从安全的角度来说,这无疑更安全。 另外一个原因选择nginx,是由于nginx服务性能很稳定,高并发能力强。
uWSGI
我们知道 Flask 中自带了 web server,通过 Werkzeug,我们可以搭建 WSGI 服务,运行我们的网站,但 Flask 是 Web 框架,并不是 Web 服务器,尽管 Werkzeug 很强大,但只能用于开发,不能用于生产,对于 Web 服务器,我们有更专业的选择,那就是 uWSGI, uWSGI 是一个全站式的托管服务,它实现了应用服务器(支持多种编程语言)、代理、进程管理器、监视器。取名为 uWSGI 是因为它最早实现的是 Python 语言的 WSGI。
uWSGI 包括四个部分:
uwsgi协议
web server 内置支持协议模块
application 服务器协议支持模块
进程控制程序
uWSGI 是 C 语言写的,性能比较高。
WSGI, uWSGI, uwsgi 的区别
当我们部署完一个应用程序,浏览网页时具体的过程是怎样的呢?首先我们得有一个 Web 服务器来处理 HTTP 协议的内容,Web 服务器获得客户端的请求,交给应用程序,应用程序处理完,返回给 Web 服务器,这时 Web 服务器再返回给客户端。Web 服务器与应用程序之间显然要进行交互,这时就出现了很多 Web 服务器与应用程序之间交互的规范,最早出现的是 CGI,后来又出现了改进 CGI 性能的FasgCGI,Java 专用的 Servlet 规范,Python 专用的 WSGI 规范等等。有了统一标准,程序的可移植性就大大提高了。这里我们只介绍 WSGI。
WSGI 全称是 Web Server Gateway Interface,也就是 Web 服务器网关接口,它是 Python 语言定义出来的 Web 服务器和 Web 应用程序之间的简单而通用的接口,基于现存的 CGI 标准设计,后来在很多其他语言中也出现了类似的接口。 总的来说,WSGI 可以分为服务器和应用程序两个部分,实际上可以将 WSGI 理解为服务器与应用程序之间的一座桥,桥的一边是服务器,另一边是应用程序。
按照 web 组件分类,WSGI 内部可以分为三类,web 应用程序,web 服务器,web 中间件。应用程序端的部分通过Python 语言的各种 Web 框架实现,比如 Flask,Django这些,有了框架,开发者就不需要处理 WSGI,框架会帮忙解决这些,开发者只需处理 HTTP 请求和响应,web 服务器的部分就要复杂一点,可以通过 uWSGI 实现,也可以用最常见的 Web 服务器,比如 Apache、Nginx,但这些 Web 服务器没有内置 WSGI 的实现,是通过扩展完成的。如 Apache,通过扩展模块 mod_wsgi 来支持WSGI,Nginx可以通过代理的方式,将请求封装好,交给应用服务器,比如 uWSGI。uWSGI 可以完成 WSGI 的服务端,进程管理以及对应用的调用。WSGI 中间件的部分可以这样理解:我们把 WSGI 看做桥,这个桥有两个桥墩,一个是应用程序端,另一个是服务器端,那么桥面就是 WSGI 中间件,中间件同时具备服务器、应用程序端两个角色,当然也需要同时遵守 WSGI 服务器和 WSGI 应用程序两边的限制和需要。更详细的内容可以看PEP-333 中间件的描述
Flask 依赖的 Werkzeug 就是一个 WSGI 工具包,官方文档的定义是 Werkzeug 是为 Python 设计的 HTTP和 WSGI 实用程序库。我们需要注意的是,Flask 自带的 Werkzeug 是用来开发的,并不能用于生产环境,Flask 是 Web 框架,而 Werkzeug 不是 Web框架,不是 Web 服务器,它只是一个 WSGI 工具包,它在 Flask 的作用是作为 Web 框架的底层库,它方便了我们的开发。
我们将 uwsgi 和 uWSGI 放在一起讲解。uWSGI 是一个 Web 服务器程序,WSGI,上面已经谈到,是一种协议,uwsgi 也是一种协议,uWSGI 实现了 uwsgi、WSGI、http 等协议。 uwsgi 的介绍可以看这里,uwsgi 是 uWSGI 使用的一个自有的协议,它用4个字节来定义传输数据类型描述。尽管都是协议,uwsgi 和 WSGI 并没有联系,我们需要区分这两个词。
Nginx
Nginx 是高效的 Web 服务器和反向代理服务器,可以用作负载均衡(当有 n 个用户访问服务器时,可以实现分流,分担服务器的压力),与 Apache 相比,Nginx 支持高并发,可以支持百万级的 TCP 连接,十万级别的并发连接,部署简单,内存消耗少,成本低,但 Nginx 的模块没有 Apache 丰富。Nginx 支持 uWSGI 的 uwsgi 协议,因此我们可以将 Nginx 与 uWSGI 结合起来,Nginx 通过 uwsgi_pass 将动态内容交给 uWSGI 处理。
官方文档在这
最好的 Nginx 教程在这
uWSGI 和 Nginx 的关系
从上面的讲解中,我们知道,uWSGI 可以起到 Web 服务器的作用,那么为什么有了 uWSGI 还需要 Nginx 呢?
最普遍的说法是 Nginx 对于处理静态文件更有优势,性能更好。其实如果是小网站,没有静态文件需要处理,只用 uWSGI 也是可以的,但加上 Nginx 这一层,优势可以很具体:
对于运维来说比较方便,如果服务器被某个 IP 攻击,在 Nginx 配置文件黑名单中添加这个 IP 即可,如果只用 uWSGI,那么就需要在代码中修改了。另一方面,Nginx 是身经百战的 Web 服务器了,在表现上 uWSGI 显得更专业,比如说 uWSGI 在早期版本里是不支持 https 的,可以说 Nginx 更安全。
nginx本身只能调用静态文件, 它需要依赖网关协议文件来调用脚本.
uwsgi是nginx的标准模块, 用于调用其它脚本.
修改nginx的配置文件conf/nginx.conf以指向uwsgi
location / {
include uwsgi_params;
uwsgi_pass 127.0.0.1:5000;
root html;
index index.html index.htm;
}
修改uwsgi文件, 配置脚本文件app_config.xml,
即运行的文件名以及应用名(nginx, uwsgi和app间需要通过socket进行交互)
<uwsgi>
<pythonpath>/home/chenjiebin/web/flaskdemo</pythonpath>
<module>flask</module>
<callable>app</callable>
<socket>127.0.0.1:5000</socket>
<master/>
<processes>4</processes>
<memory-report/>
</uwsgi>
Nginx常用的几个命令:
sudo service nginx start
sudo service nginx stop
sudo service nginx restart
2. 反向代理监听某个端口,当有客户端连接该端口,反向代理就会处理客户端的请求。所以客户端是主动的,反向代理是被动的。
2,安装部署
- 一键安装
pip install uwsgitop
- 源码安装
# 可以去pypi,搜索uwsgi下载:
https://pypi.python.org/pypi/uWSGI/
# 安装命令如下:
tar xvzf uwsgi-2.0.9.tar.gz
cd uwsgi-2.0.9
make
3,服务监控
- 读取uwsgi实时状态
uwsgi --connect-and-read uwsgi/uwsgi.status
读取的结果是个json串,包括每个总的状态,每个work是状态,响应时间等,非常全面,也有一些开源的监控可以使用
- 实时动态查看状态 - uwsgitop
这里有个uwsgi官方制作的实用工具 uwsgitop, 下面看下效果。
# pip install uwsgitop
# uwsgitop uwsgi/uwsgi.status
uwsgi-2.0.9 - Mon Sep 14 11:20:44 2015 - req: 0 - RPS: 0 - lq: 0 - tx: 0
node: lzz-rmbp - cwd: /Users/liuzhizhi/erya/portal - uid: 501 - gid: 20 - masterpid: 12748
WID % PID REQ RPS EXC SIG STATUS AVG RSS VSZ TX RunT
1 0.0 12749 0 0 0 0 idle 0ms 0 0 0 0
2 0.0 12750 0 0 0 0 idle 0ms 0 0 0 0
3 0.0 12751 0 0 0 0 idle 0ms 0 0 0 0
4 0.0 12752 0 0 0 0 idle 0ms 0 0 0 0
5 0.0 12753 0 0 0 0 idle 0ms 0 0 0 0
6 0.0 12754 0 0 0 0 idle 0ms 0 0 0 0
7 0.0 12755 0 0 0 0 idle 0ms 0 0 0 0
8 0.0 12756 0 0 0 0 idle 0ms 0 0 0 0
● 常用选项:
socket : 地址和端口号,例如:socket = 127.0.0.1:50000
processes : 开启的进程数量
workers : 开启的进程数量,等同于processes(官网的说法是spawn the specified number of workers / processes)
chdir : 指定运行目录(chdir to specified directory before apps loading)
wsgi-file : 载入wsgi-file(load .wsgi file)
stats : 在指定的地址上,开启状态服务(enable the stats server on the specified address)
threads : 运行线程。由于GIL的存在,我觉得这个真心没啥用。(run each worker in prethreaded mode with the specified number of threads)
master : 允许主进程存在(enable master process)
daemonize : 使进程在后台运行,并将日志打到指定的日志文件或者udp服务器(daemonize uWSGI)。实际上最常用的,还是把运行记录输出到一个本地文件上。
log-maxsize :以固定的文件大小(单位KB),切割日志文件。 例如:log-maxsize = 50000000 就是50M一个日志文件。
pidfile : 指定pid文件的位置,记录主进程的pid号。
vacuum : 当服务器退出的时候自动清理环境,删除unix socket文件和pid文件(try to remove all of the generated file/sockets)
disable-logging : 不记录请求信息的日志。只记录错误以及uWSGI内部消息到日志中。如果不开启这项,那么你的日志中会大量出现这种记录:
[pid: 347|app: 0|req: 106/367] 117.116.122.172 () {52 vars in 961 bytes} [Thu Jul 7 19:20:56 2016] POST /post => generated 65 bytes in 6 msecs (HTTP/1.1 200) 2 headers in 88 bytes (1 switches on core 0)
基于python的web项目,常见的部署方法有:
fcgi:用spawn-fcgi或者框架自带的工具对各个project分别生成监听进程,然后和http服务互动。
wsgi:利用http服务的mod_wsgi模块来跑各个project。
不过还有个uwsgi,它既不用wsgi协议也不用fcgi协议,而是自创了一个uwsgi的协议,据作者说该协议大约是fcgi协议的10倍那么快。uWSGI的主要特点如下:
超快的性能。
低内存占用(实测为apache2的mod_wsgi的一半左右)。
多app管理。
详尽的日志功能(可以用来分析app性能和瓶颈)。
高度可定制(内存大小限制,服务一定次数后重启等)。
环境ubuntu 12.04 IP:10.1.6.79
安装nginx
apt-get install nginx-full nginx-common
nginx配置/etc/nginx/sites-enabled/example
server {
listen 80;
server_name 10.1.6.79;
access_log /var/log/nginx/example_access.log;
error_log /var/log/nginx/example_error.log;
root /var/www/example;
location / {
uwsgi_pass 127.0.0.1:9001;
include uwsgi_params;
uwsgi_param UWSGI_SCHEME $scheme;
uwsgi_param SERVER_SOFTWARE nginx/$nginx_version;
}
}
安装uwsgi
apt-get install uwsgi uwsgi-plugin-python
如果你想安装所有的uwsgi插件,则可以安装uwsgi-plugin-all软件包
uwsgi配置/etc/uwsgi/apps-enabled/default.xml
<uwsgi>
<plugin>python</plugin>
<socket>127.0.0.1:9001</socket>
<pythonpath>/var/www/example/app/</pythonpath>
<app mountpoint="/">
<script>wsgi_configuration_module</script>
</app>
<master/>
<processes>4</processes>
<reload-mercy>8</reload-mercy>
<cpu-affinity>1</cpu-affinity>
<max-requests>2000</max-requests>
<limit-as>512</limit-as>
<reload-on-as>256</reload-on-as>
<reload-on-rss>192</reload-on-rss>
<no-orphans/>
<vacuum/>
</uwsgi>
uwsgi配置文件中的参数也可以在命令行通过uwsgi指定,配置文件除了xml格式外,还可以写成ini格式的,软件包安装完毕后在/usr/share/doc/uwsgi/examples/conffile目录下会有一些xml和ini格式配置文件的例子。
wsgi_configuration_module.py脚本内容
#!/usr/bin/python
import os
import sys
sys.path.append(‘/var/www/example/app‘)
os.environ[‘PYTHON_EGG_CACHE‘] = ‘/var/www/example/.python-egg‘
def application(environ, start_response):
status = ‘200 OK‘
output = ‘Hello World!‘
response_headers = [(‘Content-type‘, ‘text/plain‘),
(‘Content-Length‘, str(len(output)))]
start_response(status, response_headers)
return [output]
启动uwsgi
uwsgi -x /etc/uwsgi/apps-enabled/default.xml --daemonize /var/log/uwsgi/app/default.log
uwsgi 的参数:
-M 开启Master进程
-p 4 开启4个进程
-s 使用的端口或者socket地址
-d 使用daemon的方式运行, 注意, 使用-d后, 需要加上log文件地址, 比如-d /var/log/uwsgi.log
-R 10000 开启10000个进程后, 自动respawn下
-t 30 设置30s的超时时间, 超时后, 自动放弃该链接
–limit-as 32 将进程的总内存量控制在32M
-x 使用配置文件模式
并发4个线程
uwsgi -s :9090 -w myapp -p 4
主控制线程+4个线程
uwsgi -s :9090 -w myapp -M -p 4
执行超过30秒的client直接放弃
uwsgi -s :9090 -w myapp -M -p 4 -t 30
限制内存空间128M
uwsgi -s :9090 -w myapp -M -p 4 -t 30 --limit-as 128
服务超过10000个req自动respawn
uwsgi -s :9090 -w myapp -M -p 4 -t 30 --limit-as 128 -R 10000
后台运行等
uwsgi -s :9090 -w myapp -M -p 4 -t 30 --limit-as 128 -R 10000 -d uwsgi.log
除了直接用uwsgi命令启动外,还可以用init.d下的脚本启动, 不过需先修 改/etc/default/uwsgi中默认配置文件的路径,然后通过/etc/init.d/uwsgi start启动
#INHERITED_CONFIG=/usr/share/uwsgi/conf/default.ini
INHERITED_CONFIG=/etc/uwsgi/apps-enabled/default.xml
启动nginx
/etc/init.d/nginx start
以上是关于flask项目下的uwsgi配置方式及示例的主要内容,如果未能解决你的问题,请参考以下文章
centos部署flask+nginx+uwsgi之踩坑指南