uWSGI 踩坑记

一、协议的一致性

uWSGI 是在 nginx 后面,所以 nginx 转发请求时的协议要和 uWSGI 监听的协议一致。否则就会出现问题,因为是三者之间的通信,排查起来需要想清楚请求传递的次序:

Nginx -> uWSGI -> app

1.1 uWSGI 异常信息

invalid request block size: 21573 (max 4096)...skip

如果按照下面的配置就会出现上述的异常:

# Nginx 配置
location / {
    proxy_pass         http://127.0.0.1:6000;
}
# 搭配 uWSGI 配置
uwsgi --socket :6000 --wsgi-file app.py

1.2 Nginx 异常信息

upstream prematurely closed connection while reading response header from upstream, client: 120.xxx.xxx.xxx, server: hellogithub.com, request: "GET / HTTP/1.1", upstream: "uwsgi://127.0.0.1:6000", host: "hellogithub.com"

原因是:nginx 为 uwsgi 协议,uWSGI 为 http 协议,那么请求会到不了 uWSGI。

1.3 正确配置示例:

1.通过 uwsgi 协议传递请求

# Nginx 配置
location / {
    include uwsgi_params;
    uwsgi_pass 127.0.0.1:6000;
}
# 搭配 uWSGI 配置
uwsgi --socket :6000 --wsgi-file app.py

上述配置的的意思是说 “把每个请求传递到服务器绑定的端口 6000,并且使用 uwsgi 协议通信”。

2.通过 http 协议传递请求(不推荐)

# Nginx 配置
location / {
    proxy_set_header   Host             $host;
    proxy_set_header   X-Real-IP        $remote_addr;
    proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
    proxy_pass         http://127.0.0.1:6000;
}
# 搭配 uWSGI 配置
uwsgi --http :6000 --wsgi-file app.py

每个请求通过 http 协议传递给 6000端口的服务,但是服务应用想要获得请求的真实 IP 和请求的 http 信息需要在 nginx 中额外配置。

二、配置参数

2.1 指定配置文件启动时

1.切记配置文件中要有 pidfile 参数

pidfile=/tmp/myproject-master.pid 

否则 supervisor 重启 uWSGI 不会关闭进程,而且为不报错。

TODO这样可能会导致另外一个异常,我现在如果使用指定 ini 文件启动就会报这个问题,后面查到原因再来写:

robably another instance of uWSGI is running on the same address (:6000).
bind(): Address already in use [core/socket.c line 769]

2.2 启动 gevent

uwsgi --gevent 100 --gevent-monkey-patch --http :9090 -M --processes 4 --wsgi-file wsgi.py

增加 --gevent-monkey-patch 参数可以不用修改代码就采用 gevent 方式启动。

2.3 环境变量

supervisor 配置的环境变量不会传递给uWSGI启动的服务。举个例子:

## supervisor 配置
environmenit=name=hellogithub

## app 代码片段
pro_name = os.getenv(‘name‘)

这时 pro_name 会返回 None 而不是预期的 hellogithub,所以启动 uWSGI 时需要增加环境变量参数:--env name=hellogithub,如此可达到预期。

三、参考

原文地址:https://www.cnblogs.com/xueweihan/p/9060065.html

时间: 2024-11-09 05:10:45

uWSGI 踩坑记的相关文章

<<Python编程:从入门到实践>>踩坑记 Django

<<Python编程:从入门到实践>>踩坑记 Django Django Python 19.1.1.5 模板new_topic 做完书上的步骤后,对主题添加页面经行测试,但是浏览器显示 服务器异常. 个人采用的开发环境是virtual studio code , 测试起来很是难受,因为我配置的debug环境,断点操作没有作用. 经过我不断的测试,才发现我失败的原因是由于之前的误操作,先建立new_pizzas.py后改为new_pizzas.html的,错误就在这里.在我之后新建

踩坑记:httpComponents 的 EntityUtils

今天写的一个服务程序,有人报告获得的数据中文乱码,而我是用 apache 通过 httpComponents 去取得数据的,于是开启日志的 debug 级别. 在日志里果然发现中文不见了,有乱码出现: 2014-07-02 16:35:01.348 DEBUG [Wire.java:86] http-outgoing-8 << "<?xml version="1.0" encoding="UTF-8"?>... subject=&q

Spark踩坑记——数据库(Hbase+Mysql)转

转自:http://www.cnblogs.com/xlturing/p/spark.html 前言 在使用Spark Streaming的过程中对于计算产生结果的进行持久化时,我们往往需要操作数据库,去统计或者改变一些值.最近一个实时消费者处理任务,在使用spark streaming进行实时的数据流处理时,我需要将计算好的数据更新到hbase和mysql中,所以本文对spark操作hbase和mysql的内容进行总结,并且对自己踩到的一些坑进行记录. Spark Streaming持久化设计

Spring @Transactional踩坑记

@Transactional踩坑记 总述 ? Spring在1.2引入@Transactional注解, 该注解的引入使得我们可以简单地通过在方法或者类上添加@Transactional注解,实现事务控制. 然而看起来越是简单的东西,背后的实现可能存在很多默认规则和限制.而对于使用者如果只知道使用该注解,而不去考虑背后的限制,就可能事与愿违,到时候线上出了问题可能根本都找不出啥原因. 踩坑记 1. 多数据源 事务不生效 背景介绍 ? 由于数据量比较大,项目的初始设计是分库分表的.于是在配置文件中

[转]Spark 踩坑记:数据库(Hbase+Mysql)

https://cloud.tencent.com/developer/article/1004820 Spark 踩坑记:数据库(Hbase+Mysql) 前言 在使用Spark Streaming的过程中对于计算产生结果的进行持久化时,我们往往需要操作数据库,去统计或者改变一些值. 最近一个实时消费者处理任务,在使用spark streaming进行实时的数据流处理时,我需要将计算好的数据更新到hbase和mysql中,所以本文对spark操作hbase和mysql的内容进行总结,并且对自己

记一次 Spring 事务配置踩坑记

记一次 Spring 事务配置踩坑记 问题描述:(SpringBoot + MyBatisPlus) 业务逻辑伪代码如下.理论上,插入数据 t1 后,xxService.getXxx() 方法的查询条件会不满足,会查询不到数据.结果事与愿违,后一次的查询,居然查到了数据. void saveXxx(){  xxService.getXxx(); // 查到一条数据 data1  xxService.insert(); // 插入一条数据 t1  xxService.getXxx(); // 查到

阿里云ECS搭建Kubernetes集群踩坑记

阿里云ECS搭建Kubernetes集群踩坑记 [TOC] 1. 现有环境.资源 资源 数量 规格 EIP 1 5M带宽 ECS 3 2 vCPU 16 GB内存 100G硬盘 ECS 3 2 vCPU 16 GB内存 150G硬盘 SLB 2 私网slb.s1.small 2. 规划 坑: 上网问题,因为只有一个EIP,所有其它节点只能通过代理上网; 负载均衡问题,因为阿里不支持LVS,负载均衡TCP方式后端又不支持访问负载均衡,HTTP和HTTPS方式,只支持后端协议为HTTP; 为了避免上

HttpWebRequest 改为 HttpClient 踩坑记-请求头设置

HttpWebRequest 改为 HttpClient 踩坑记-请求头设置 Intro 这两天改了一个项目,原来的项目是.net framework 项目,里面处理 HTTP 请求使用的是 WebReauest,但是 WebRequest 已经不再推荐使用了,你如果在项目中使用的话,编译器会警告, WebRequest已过时,新项目要 .Net standard 重写就直接 HttpClient 来处理 HTTP 请求了,在改的过程中踩了几个坑,记录一下 请求头处理 HttpClient 通常

windows container 踩坑记

windows container 踩坑记 Intro 我们有一些服务是 dotnet framework 的,不能直接跑在 docker linux container 下面,最近一直在折腾把它部署在 windows container 下,折腾的有点恶心,记录一下. Windows Container 介绍 Windows Container 是微软在 Windows 上的虚拟化实践,它可以提供操作系统级别的虚拟化. 通过我们说的容器化大多是指 Linux Container,基于 linu