1、创建数据库、账号,并授权该账号
2、安装所需 Python 版本并基于该版本创建虚世碧拟环境
CentOS 6.4 自带的 Python 版本是 2.6,不用它,另外装个 2.7 的。
install python 2.7.3 to /usr/local/python273
install Virtualenv
创建虚拟环境并激活
virtualenv --python=/usr/local/python273/bin/python /var/www/env-py273
source /var/www/env-py273/bin/activate
3、唤蠢安装 Django 及其它所需的 Python 第三方库
pip install django==1.5.1
pip install MySQL-python==1.2.4
pip install PyYAML==3.10
......
4、把项目放上服务器
项目的目录结构:
项目名称:build
项目的路径:/var/www/build,项目的日志放在:/var/log/build
mkdir -p /var/log/build &&cd /var/www
git clone git@192.168.66.77:scm/build.git
5、配置 uwsgi、nginx
uwsgi 的配置文件:build/build_uwsgi,和返陪nginx 的配置文件:build/appdata/nginx-uwsgi.conf
cd build
touch build_uwsgi.sock
ln -s appdata/nginx-uwsgi.conf /etc/nginx/conf.d/
6、启动 uwsgi、nginx
nohup uwsgi --ini build_uwsgi.ini&
service nginx restart
大功告成,可以在浏览器访问你的应用了。
uwsgi监听的socket,可以为socket文件或ip地址+端口号socket = /www/wwwroot/web/script/uwsgi.sock
socket = :8080
用nginx的时候就配socket , 直接运行的时候配 http
指定IP端口 // 直接外部访问
http-socket = 127.0.0.1:8080
指定项目的目录,在app加载前切换到当前目录
指定项目的application,加载指定的python WSGI模块(模块路径必须在PYTHONPATH里)
相当于master=true,启动一个master进程来管理其他进程,以上述配置为例,其中的4个uwsgi进程都是这高源手个master进程的子进程,如果kill这个master进程,相当于重启所有的uwsgi进程
开启的进程数量(和worker作用相同)
uid = www
gid = www
进程个数
processes = 5
pidfile = /www/wwwroot/web/script/uwsgi.pid
自动移除unix Socket 和 Pid 文件 当服务停止的时候
vacuum = true
序列化接受的内容,如果可能的话
thunder-lock = true
启用线程
enable-threads = true
设置缓冲
post-buffering = 4096
设置静态文件
static-map = /static=//www/wwwroot/mysite/static
使进程在后台运行,并将日志打到指定的日志文件或者udp服务器(不会影响nginx日志的输出)
daemonize = /www/wwwroot/mysite/uwsgi.log
给PYTHONPATH 增加一个目录(或者一个egg),最多可以使用该选项64次。
在失去权限前,将master的pid写到当前文件中
设置默认的通信协议(uwsgi,http,fastcgi)
这个选项会设置harakiri超时时间(可以看wiki首页的相关内容)。如果一个请求花费的时间超过了这个harakiri超时时间戚嫌,那么这个请求都会被丢弃,并且当前处理这个请求的工作进程会被回收再利用(即重启)。
设置用于uwsgi包解析的内部缓存区大小。默认是4k。
如果你打算接受一个拥有很多请求头的大请求,你可以增加这个值到64k。
这个命令会允许uWSGI服务器接收最大为32k的uwsgi包,再大的包就会被拒绝。
unix socket是个文件,所以会受到unix系统的权限限制。如果你的uwsgi客户端没有权限访问uWSGI socket,你可以用这个选项设置unix socket的权限。
当在xml配裂敏置文件中只是用这个选项作为一个标识符,那么会将权限设为666,否则就是设置为指定的权限值。
chmod-socket = 755
这个选项将自动给uWSGI的进程设置一些有意义的名字,例如“uWSGI master”, “uWSGI worker 1”, “uWSGI worker 2”。
为所有的socket *** 作设置内部超时时间(默认4秒)。
这个配置会结束那些处于不活动状态超过10秒的连接。
近期使用uwsgi启动django服务,发现在stop/reload uwsgi时会出现hangs问题,具体日志表现为:
在测试中发现无论用什么防线先uwsgi发送stop/reload信号,uwsgi都会进入一种假死状态,即不接收请求,也不结束进程。
期旁氏初以为uwsgi进程是在处理未完成的web请求。后来发现在没有任何请求时,uwsgi也会进入这种夯死状态。
首先说明问题的原因是因何而起。
出现这种夯死的问题是由于在uwsgi中使用了线程导致。
这里创建了一个最简单的django服务,并用uwsgi来启动。
首先,配置uwsgi为进程模式启橡启皮动,这里创建了5个进程。
uwsgi配置文件如下:
现在来reload uwsgi服务,并查看uwsgi的日志。
结论:在uwsgi使用进程模式时,reload uwsgi不会出现夯死的问题。
前面以进程方式启动uwsgi没有出现夯死问题,那么现在就试一下以线程模式启动wusgi。这里启动了5个进程,每个进程中又包含了两个梁差线程。
uwsgi配置文件如下:
reload uwsgi服务,并观察日志输出。
结论:在uwsgi中使用线程模式也不会造成reload夯死的问题。
uwsgi的线程不会造成任何问题,那前文所指的线程究竟是什么?
现在uwsgi启动脚本中创建一个线程,在这种情况下尝试reload uwsgi并查看日志输出。
随后以线程方式启动uwsgi,并reload uwsgi。
结论:在uwsgi app中使用线程就导致reload夯死。
若场景中非要在uwsgi app中使用线程,可以通过配置 reload-mercy 和 worker-reload-mercy 两个参数避免夯死的问题。
uwsgi配置文件如下:
再次reload uwsgi服务,输出日志如下:
这里虽然也会出现NO MERCY问题,但是uwsgi在reload过程中并没有出现夯死的情况。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)