Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cheaper mode do not spawn worker after first timeout #152

Closed
jeanlucmongrain opened this issue Feb 9, 2013 · 6 comments · Fixed by #153
Closed

Cheaper mode do not spawn worker after first timeout #152

jeanlucmongrain opened this issue Feb 9, 2013 · 6 comments · Fixed by #153

Comments

@jeanlucmongrain
Copy link

I have this server I use only for integration tests by my dev team. Each time a git push is made, this server is updated.

But as I have a lot of projects, I can't have all of them running all the time and consume memory. So I wanted to have uwsgi to launch them only if someone try to get on the proper virtualhost.

It work well until uwsgi kill the worker for innactivity, after that it don't respawn new workers.

uwsgi config:

[uwsgi]
master = true
processes = 1
cheap = true
cheaper = 0
cheaper-busyness-verbose = true
idle = 15 # this is just to show the problem, the real value is 300
cheaper-initial = 0
ksm = 10
lazy-apps = true
uid = www-data
gid = www-data
virtualenv = /usr/local/deployments/test
chdir = /usr/local/deployments/test
procname = test-worker
procname-master = test-master
socket = /var/lib/uwsgi/test.sock
module = test.wsgi:application
no-orphans = true

Running uwsgi:

[uWSGI] getting INI configuration from /tmp/test.ini
*** Starting uWSGI 1.4.3 (32bit) on [Sat Feb  9 11:58:32 2013] ***
compiled with version: 4.6.3 on 28 January 2013 10:54:41
os: Linux-3.2.0-24-virtual #37-Ubuntu SMP Wed Apr 25 12:51:49 UTC 2012
nodename: dev
machine: i686
clock source: unix
detected number of CPU cores: 1
current working directory: /etc/uwsgi
detected binary path: /usr/local/uwsgi/uwsgi
setgid() to 33
setuid() to 33
your processes number limit is 3922
your memory page size is 4096 bytes
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
uwsgi socket 0 bound to UNIX address /var/lib/uwsgi/test.sock fd 6
Python version: 2.7.3 (default, Aug  1 2012, 05:27:35)  [GCC 4.6.3]
Set PythonHome to /usr/local/deployments/test
*** Python threads support is disabled. You can enable it with --enable-threads ***
Python main interpreter initialized at 0x9db9110
your server socket listen backlog is limited to 100 connections
mapped 127584 bytes (124 KB) for 1 cores
*** Operational MODE: single process ***
*** uWSGI is running in multiple interpreter mode ***
[uwsgi-KSM] enabled with frequency: 10
spawned uWSGI master process (pid: 30266)
cheap mode enabled: waiting for socket connection...

Now I that it had started, get / on Nginx:

spawned uWSGI worker 1 (pid: 30271, cores: 1)
WSGI app 0 (mountpoint='') ready in 1 seconds on interpreter 0x9db9110 pid: 30271 (default app)
[pid: 30271|app: 0|req: 1/1] 203.218.215.120 () {44 vars in 1164 bytes} [Sat Feb  9 11:58:44 2013] GET / => generated 8970 bytes in 1937 msecs (HTTP/1.1 200) 2 headers in 73 bytes (1 switches on core 0)

Wait until the worker is killed:

workers have been inactive for more than 15 seconds (1360411143-1360411127)
cheap mode enabled: waiting for socket connection...

Try to do an other get / on Nginx:

workers have been inactive for more than 15 seconds (1360411185-1360411169)
cheap mode enabled: waiting for socket connection...
workers have been inactive for more than 15 seconds (1360411202-1360411186)
cheap mode enabled: waiting for socket connection...
workers have been inactive for more than 15 seconds (1360411219-1360411203)
cheap mode enabled: waiting for socket connection...
workers have been inactive for more than 15 seconds (1360411236-1360411220)
cheap mode enabled: waiting for socket connection...
workers have been inactive for more than 15 seconds (1360411253-1360411237)
cheap mode enabled: waiting for socket connection...

No more worker spawning?
After a while Nginx return 504 Gateway Timeout.

And it loop like that until I interrupt it:

^CSIGINT/SIGQUIT received...killing workers...
goodbye to uWSGI.
@prymitive
Copy link
Contributor

Most likely due to cheaper = 0
Cheaper is for scaling workers based on the load, its value should be the minimum number of workers to keep and 0 is invalid value for it (only >= 1 <= $(--workers) should be accepted).

If You want all workers to be stopped if not needed, than use --idle <seconds> option, uWSGI will stop all workers after given number of seconds of idleness.

I'll check if --cheaper is validated properly.

EDIT: You have --idle so just remove cheaper = 0

@jeanlucmongrain
Copy link
Author

I tried to remove cheaper = 0, and I get the same results:

spawned uWSGI master process (pid: 32753)
cheap mode enabled: waiting for socket connection...
spawned uWSGI worker 1 (pid: 315, cores: 1)
WSGI app 0 (mountpoint='') ready in 2 seconds on interpreter 0x87b70c0 pid: 315 (default app)
[pid: 315|app: 0|req: 1/1] 203.218.215.120 () {44 vars in 1164 bytes} [Sat Feb  9 12:30:55 2013] GET / => generated 8970 bytes in 2016 msecs (HTTP/1.1 200) 2 headers in 73 bytes (1 switches on core 0)
workers have been inactive for more than 15 seconds (1360413073-1360413057)
cheap mode enabled: waiting for socket connection...

2nd GET:

workers have been inactive for more than 15 seconds (1360413108-1360413092)
cheap mode enabled: waiting for socket connection...
workers have been inactive for more than 15 seconds (1360413125-1360413109)
cheap mode enabled: waiting for socket connection...
workers have been inactive for more than 15 seconds (1360413142-1360413126)
cheap mode enabled: waiting for socket connection...
workers have been inactive for more than 15 seconds (1360413159-1360413143)
cheap mode enabled: waiting for socket connection...
workers have been inactive for more than 15 seconds (1360413176-1360413160)

@prymitive
Copy link
Contributor

With 1.4.3 you also need to remove cheaper-initial = 0, this should be handled better in new releases.

@jeanlucmongrain
Copy link
Author

and that work!

@prymitive
Copy link
Contributor

Can you close this report if it works?

@jeanlucmongrain
Copy link
Author

yes thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants