在M1 Mac上启动amd64 uWSGI容器会导致极端的队列填充



当我试图在M1 Mac上启动一个包含uWSGI服务的容器时,我会得到一种似乎不太可能的侦听队列行为。日志如下,然后是更多详细信息:

[uWSGI] getting INI configuration from ./config/uwsgi/uwsgi_cells.ini
*** Starting uWSGI 2.0.20 (64bit) on [Fri Aug 12 15:57:43 2022] ***
compiled with version: 10.2.1 20210110 on 12 August 2022 15:53:41
os: Linux-5.10.104-linuxkit #1 SMP PREEMPT Thu Mar 17 17:05:54 UTC 2022
nodename: 272fb4e4e089
machine: x86_64
clock source: unix
pcre jit enabled
detected number of CPU cores: 5
current working directory: /usr/local/employer
detected binary path: /usr/local/employer/venv/bin/uwsgi
*** dumping internal routing table ***
[rule: 0] subject: path_info regexp: ^/operations/healthcheck/liveness/ action: return:200
[rule: 1] subject: path_info regexp: ^/operations/healthcheck/readiness/ action: return:200
*** end of the internal routing table ***
*** dumping internal response routing table ***
[rule: 0] action: last:
*** end of the internal response routing table ***
your memory page size is 4096 bytes
*** WARNING: you have enabled harakiri without post buffering. Slow upload could be rejected on post-unbuffered webservers *** 
detected max file descriptor number: 1048576
- async cores set to 100 - fd table size: 1048576
lock engine: pthread robust mutexes
!!! it looks like your kernel does not support pthread robust mutexes !!!
!!! falling back to standard pthread mutexes !!!
thunder lock: disabled (you can enable it with --thunder-lock)
[busyness] settings: min=10%, max=50%, overload=32, multiplier=8, respawn penalty=2
[busyness] backlog alert is set to 64 request(s), step is 1
[busyness] backlog non-zero alert is set to 5 second(s)
uwsgi socket 0 bound to TCP address :5000 fd 8
Python version: 3.9.13 (main, May 18 2022, 02:18:18)  [GCC 10.2.1 20210110]
Python main interpreter initialized at 0x400015db30
python threads support enabled
your server socket listen backlog is limited to 400 connections
your mercy for graceful operations on workers is 60 seconds
mapped 123283388 bytes (120393 KB) for 1600 cores
*** Operational MODE: preforking+async ***
Loading local Docker configuration...
Loading local Docker configuration...
WSGI app 0 (mountpoint='') ready in 15 seconds on interpreter 0x400015db30 pid: 1 (default app)
spawned uWSGI master process (pid: 1)
spawned uWSGI worker 1 (pid: 14, cores: 100)
spawned uWSGI worker 2 (pid: 16, cores: 100)
spawned uWSGI worker 3 (pid: 18, cores: 100)
running "unix_signal:15 gracefully_kill_them_all" (master-start)...
*** running gevent loop engine [addr:0x40000b2590] ***
Fri Aug 12 15:57:59 2022 - *** uWSGI listen queue of socket ":5000" (fd: 8) full !!! (26486256/64) ***
[busyness] 26486256 requests in listen queue, spawning 1 emergency worker(s) (1)!
spawned uWSGI worker 4 (pid: 29, cores: 100)
Fri Aug 12 15:58:00 2022 - *** uWSGI listen queue of socket ":5000" (fd: 8) full !!! (26486256/64) ***
[busyness] 26486256 requests in listen queue, spawning 1 emergency worker(s) (2)!
spawned uWSGI worker 5 (pid: 34, cores: 100)
Fri Aug 12 15:58:01 2022 - *** uWSGI listen queue of socket ":5000" (fd: 8) full !!! (26486256/64) ***
[busyness] 26486256 requests in listen queue, spawning 1 emergency worker(s) (3)!
spawned uWSGI worker 6 (pid: 39, cores: 100)
Fri Aug 12 15:58:02 2022 - *** uWSGI listen queue of socket ":5000" (fd: 8) full !!! (26486256/64) ***
[busyness] 26486256 requests in listen queue, spawning 1 emergency worker(s) (4)!
spawned uWSGI worker 7 (pid: 44, cores: 100)

关键是:

*** uWSGI listen queue of socket ":5000" (fd: 8) full !!! (26486256/64) ***

服务启动后每秒钟重复一次。很明显,我的服务没有26486256个挂起的连接。业务一直在努力培养新的员工,直到达到最大值,但奇怪的是,向服务提出请求确实有效。

我正在努力发现日志垃圾邮件的原因,以及它是否真的会成为我的开发环境之外的任何地方的问题。这让我们更难看清到底发生了什么

我遇到了同样的问题,但我无法向服务发出请求。在.ini配置文件中设置master = false为我解决了这个问题https://bytemeta.vip/repo/unbit/uwsgi/issues/2406)

最新更新