ING-XIAOJIAN commented 1 year ago

Describe the bug It occurred an issue of RECV-Q block When I used UWSGI to load a flask app, as shown below The RECV-Q will increase by one when I use postman to send a request!!! After a while, The RECV-Q is full!!

Does anyone have some ideal?

UWSGI version

Starting uWSGI 2.0.17 (64bit) on [Thu Mar 30 19:14:02 2023] compiled with version: 8.3.1 20191121 (Red Hat 8.3.1-5) on 20 October 2020 09:12:55 os: Linux-4.18.0-240.1.1.el8_3.x86_64 #1 SMP Thu Nov 19 17:20:08 UTC 2020 nodename: xxxx machine: x86_64 clock source: unix detected number of CPU cores: 4 current working directory: xxxxx detected binary path:/xxx/xxx/uwsgi/uwsgi !!! no internal routing support, rebuild with pcre support !!! uWSGI running as root, you can use --uid/--gid/--chroot options WARNING: you are running uWSGI as root !!! (use the --uid flag) WARNING: you are running uWSGI without its master process manager your processes number limit is 30938 your memory page size is 4096 bytes detected max file descriptor number: 1024 lock engine: pthread robust mutexes thunder lock: disabled (you can enable it with --thunder-lock) uWSGI running as root, you can use --uid/--gid/--chroot options WARNING: you are running uWSGI as root !!! (use the --uid flag) uWSGI running as root, you can use --uid/--gid/--chroot options WARNING: you are running uWSGI as root !!! (use the --uid flag) The -s/--socket option is missing and stdin is not a socket.

Dsitro

System:Centos8
Architecture:x86_64

UWSGI configuration

[uwsgi] uid = nobody gid = nobody master = true chmod-socket = 666 pidfile = /var/run/test.pid processes = 2 threads = 4 chdir = /tmp/xxx/xxx callable = application pythonpath = /tmp/xxx/xxx module = xxx http = 0.0.0.0:9900 logto = xxx touch-logreopen = xxx stopsignal = QUIT stopwaitsecs = 10 socket-timeout = 600 http-timeout = 600 harakiri = 600 reload-on-as = 24576 reload-on-rss = 24576 evil-reload-on-as = 24576 evil-reload-on-rss = 24576

Flask app code

#!/usr/bin/env python
# -*- coding: utf-8 -*-
import sys
import threading
import time
from os import path
from threading import Thread
from flask import Flask
from flask import jsonify

def thread_test():
    while (True):
        lock = threading.Condition()
        lock.acquire()
        dosomething(have some socket communication)
        time.sleep(5)
        print("input thread")
        lock.release()

t = Thread(target=thread_test)
s = Thread(target=thread_test)
s.setDaemon(True)
t.setDaemon(True)
t.start()
s.start()

application = Flask(__name__)
@application .route("/v1/demo", methods=["POST"])
def test_invoke_chain():
    data = {
        "code": 0,
        "msg": "success",
        "data": {}
    }
    return jsonify(data)

if __name__ == '__main__':
    application.run(host="0.0.0.0", port=9900, debug=True, threaded=True)

ING-XIAOJIAN commented 1 year ago

2472 related question

ING-XIAOJIAN commented 1 year ago

I have done a deeper investigation, Maybe workers have a deadlock, I used GDB to attach worker's pid, as shown below

(gdb) info threads
  Id   Target Id                                   Frame
* 1    Thread 0x7ff12f23b740 (LWP 1760470) "uwsgi" futex_abstimed_wait_cancelable (private=0,
    abstime=0x0, expected=0, futex_word=0x1aa4b40)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:205
(gdb) py-bt
Traceback (most recent call first):
  Waiting for the GIL

unbit / uwsgi

uwsgi recv-q block #2527

2472 related question