Question

我已经使用Nginx作为代理使用Python2.7和Uwsgi Server构建了一个API。

在使用请求方法大小约为4KB的POST方法进行负载测试期间，我在Nginx错误日志中遇到了以下类似错误

2018/08/22 10:36:31 [error] 4811#4811: *9780 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 172.31.25.251, server: localhost, request: "POST /api/XXXXXXX HTTP/1.1", upstream: "uwsgi://127.0.0.1:16543", host: "XYZ.ABC.com"

2018/08/22 10:36:34 [error] 4811#4811: *9412 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 172.31.25.251, server: localhost, request: "POST /api/XXXXXXX HTTP/1.1", upstream: "uwsgi://127.0.0.1:16543", host: "XYZ.ABC.com"

2018/08/22 07:21:03 [info] 2890#2890: *257 epoll_wait() reported that client prematurely closed connection, so upstream connection is closed too while connecting to upstream, client: 172.31.34.179, server: localhost, request: "POST /api/XXXXXXX HTTP/1.1", upstream: "uwsgi://127.0.0.1:16543", host: "XYZ.ABC.com"

例如，如果我每分钟发出10,000个请求，则在Nginx访问日志中会看到10,000个请求。 Nginx错误日志中有1,000个错误，Uwsgi日志中有9,000个（成功）请求。

我在Uwsgi日志中没有看到任何错误，这让我思考问题出在哪里？

Nginx conf

error_log  /var/log/nginx/error.log info;
worker_processes  auto;
worker_rlimit_nofile 65535;

events {
   worker_connections  65535;
   use epoll;
   multi_accept on;
}

http {
   include       /etc/nginx/mime.types;
   default_type  application/json;
   fastcgi_buffers 8 16k;
   fastcgi_buffer_size 32k;
   fastcgi_connect_timeout 300;
   fastcgi_send_timeout 300;
   fastcgi_read_timeout 300;
   client_max_body_size 5m;
   client_body_buffer_size      128k;
   client_header_buffer_size    1k;
   large_client_header_buffers  4 4k;
   client_header_timeout  3m;
   client_body_timeout    3m;
   send_timeout           3m;
   reset_timedout_connection on;

   sendfile        on;
   #tcp_nopush     on;
   tcp_nopush on;
   tcp_nodelay on;

   keepalive_timeout  200;
   keepalive_requests  2000;

   #gzip  on;
   log_format mycombined '$status $remote_addr [$time_local] "$request" $body_bytes_sent $request_length $request_time $upstream_response_time $pipe';
   map $status $loggable {
       ~^[23]  0;
       default 1;
   }

   server {
       listen       80;
       server_name  localhost;
       access_log /var/log/nginx/access.log mycombined;
       location / {
            expires -1;
            include uwsgi_params;
            uwsgi_read_timeout  60;
            uwsgi_pass 127.0.0.1:16543;
       }
       location /_health {
            expires -1;
            include uwsgi_params;
            uwsgi_read_timeout  60;
            uwsgi_pass 127.0.0.1:16543;
       }
       #location ~ \.(txt) {
       #     root /path/to/dir/;
       #}
   }
}

Uwsgid conf

[program:uwsgi]
command=uwsgi --ini-paste /some/path/uwsgi.ini
autorestart=true
redirect_stderr=true
stdout_logfile=/var/log/uwsgi/uwsgi.log
stdout_logfile_maxbytes=100MB
stdout_logfile_backups=10
stdout_capture_maxbytes=10MB
stdout_events_enabled=false
loglevel=warn

Uwsgi.ini文件

[uwsgi]
master = true
thunder-lock = true
master-fifo = /tmp/some_uwsgi_fifo_0
processes = 4
enable-threads = true
threads = 8
harakiri = 360
max-requests = 100000
post-buffering = 8192
worker-reload-mercy = 300
reload-mercy = 300
module = module_name
callable = application
stats = /tmp/some_uwsgi.socket
socket = 127.0.0.1:16543

我的机器上有4个vCPU，因此我已经通过使用4个Nginx worker进程和4个Uwsgi进程来利用机器的全部功能。尽管我的服务器计算机的CPU使用率即使在20,000个请求/分钟时也不会超过25％。

我没有在这台机器上进行所有与应用程序相关的计算。只是请求验证和一些字典操作，然后我将其推送到队列并将响应返回给客户端。所以我假设CPU不是问题。

我了解到Nginx和Uwsgi conf中的超时都可能解决此问题（我们尚未尝试过，因为它是时间紧迫的应用，我们不想增加超时）。

我们已经在Nginx中使用了很少的参数，例如keepalive-requests等，在Uwsgi中使用了很少的参数，例如max-worker-lifetime，在Uwsgi中增加了进程数量，这是最好的配置（Nginx和Uwsgi）导致错误率最低。

您能帮我吗？ Nginx是否已向Uwsgi发送请求？如果是，为什么不在Uwsgi日志中？如果是Uwsgi问题，我在哪里可以找到错误日志？

所有这些错误分别表示什么？

Nginx和Uwsgi服务器：上游超时（110：连接超时）。 Uwsgi日志中没有错误

0 个答案: