uwsgi的log怎么配置

系统环境：CentOS 6.4、Python 2.7.3、Django 1.5.1、MySQL 5.1、nginx、uwsgi、virtualenv

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过程中并没有出现夯死的情况。

---