Veo una situación extraña en la que Nginx o uwsgi parecen estar acumulando una larga cola de solicitudes entrantes e intentando procesarlas mucho después de que se agotó el tiempo de espera de la conexión del cliente. Me gustaría entender y detener ese comportamiento. Aquí hay más información:

Mi configuración

Mi servidor utiliza Nginx para pasar solicitudes POST HTTPS a uWSGI y Flask a través de un socket de archivo Unix. Básicamente tengo las configuraciones predeterminadas en todo.

Tengo un cliente Python que envía 3 solicitudes por segundo a ese servidor.

El problema

Después de ejecutar el cliente durante aproximadamente 4 horas, la máquina del cliente comenzó a informar que todas las conexiones se estaban agotando. (Utiliza la biblioteca de solicitudes de Python con un tiempo de espera de 7 segundos). Aproximadamente 10 minutos después, el comportamiento cambió: las conexiones comenzaron a fallar con 502 Bad Gateway.

Apagué el cliente. ¡Pero durante aproximadamente 10 minutos DESPUÉS de apagar el cliente, los registros uWSGI del lado del servidor mostraron que uWSGI intentaba responder a las solicitudes de ese cliente! Ytop mostró uWSGI usando 100% de CPU (25% por trabajador).

Durante esos 10 minutos, cadauwsgi.log la entrada se veía así:

Thu May 25 07:36:37 2017 - SIGPIPE: writing to a closed pipe/socket/fd (probably the client disconnected) on request /api/polldata (ip 98.210.18.212) !!! Thu May 25 07:36:37 2017 - uwsgi_response_writev_headers_and_body_do(): Broken pipe [core/writer.c line 296] during POST /api/polldata (98.210.18.212) IOError: write error [pid: 34|app: 0|req: 645/12472] 98.210.18.212 () {42 vars in 588 bytes} [Thu May 25 07:36:08 2017] POST /api/polldata => generated 0 bytes in 28345 msecs (HTTP/1.1 200) 2 headers in 0 bytes (0 switches on core 0)

Y el Nginxerror.log muestra mucho de esto:

2017/05/25 08:10:29 [error] 36#36: *35037 connect() to unix:/srv/my_server/myproject.sock failed (11: Resource temporarily unavailable) while connecting to upstream, client: 98.210.18.212, server: example.com, request: "POST /api/polldata HTTP/1.1", upstream: "uwsgi://unix:/srv/my_server/myproject.sock:", host: "example.com:5000"

Después de aproximadamente 10 minutos, la actividad de uWSGI se detiene. Cuando vuelvo a encender el cliente, Nginx acepta felizmente las solicitudes POST, pero uWSGI da el mismo error de "escribir en una tubería cerrada" en cada solicitud, como si de alguna manera estuviera roto permanentemente. Reiniciar el contenedor docker del servidor web no soluciona el problema, pero reiniciar la máquina host lo soluciona.

Teorías

En la configuración predeterminada de Nginx -> socket -> uWSGI, ¿hay una larga cola de solicitudes sin tiempo de espera? Miré en los documentos uWSGI y vi un montón de tiempos de espera configurables, pero todos predeterminados a alrededor de 60 segundos, por lo que no puedo entender cómo veo que se manejan las solicitudes de hace 10 minutos. No he cambiado ninguna configuración de tiempo de espera predeterminada.

La aplicación utiliza casi todos los 1 GB de RAM en mi pequeño servidor de desarrollo, por lo que creo que los límites de recursos pueden estar desencadenando el comportamiento.

De cualquier manera, me gustaría cambiar mi configuración para que las solicitudes de más de 30 segundos se eliminen con un error 500, en lugar de ser procesadas por uWSGI. Agradecería cualquier consejo sobre cómo hacerlo y teorías sobre lo que está sucediendo.