Hi, On Fri, 4 May 2012 12:18:22 +0200 Marcin Deranek <[email protected]> wrote:
> On Fri, 4 May 2012 11:10:52 +0200 > Roberto De Ioris <[email protected]> wrote: > > > I think adding a check for "paused state" will be enough: > > > > http://projects.unbit.it/uwsgi/browser/master.c#L729 > > > > if uwsgi.workers[0].suspended is 1 it means uWSGI is paused > > Although in the last scenario (single "idle" worker and a bunch of > "paused" & "cheap" workers) I used cheaper mode not sure if this is > a more generic case when worker gets recycled during > pausing master daemon. There seems to be another case when worker gets into 'idle' state after uWSGI being suspended (worker 15 in our case): Thu Feb 7 13:33:04 2013 - ...The work of process 29281 is done. Seeya! Thu Feb 7 13:33:05 2013 - Respawned uWSGI worker 15 (new pid: 29294) Thu Feb 7 13:33:05 2013 - *** psgix.harakiri.commit requested *** Thu Feb 7 13:33:05 2013 - ...The work of process 29215 is done. Seeya! Thu Feb 7 13:33:06 2013 - Respawned uWSGI worker 14 (new pid: 29347) Thu Feb 7 13:33:09 2013 - *** psgix.harakiri.commit requested *** Thu Feb 7 13:33:09 2013 - ...The work of process 29347 is done. Seeya! Thu Feb 7 13:33:10 2013 - Respawned uWSGI worker 14 (new pid: 29618) Thu Feb 7 13:33:10 2013 - DONE Constructing Plack builder for uWSGI Thu Feb 7 13:33:10 2013 - PSGI app 0 (/usr/local/git_tree/main/config/plack/app.psgi) loaded in 13 seconds at 0x1a55abf0 (interpreter 0x198ed980) Thu Feb 7 13:33:10 2013 - *** daemonizing uWSGI *** Thu Feb 7 13:33:10 2013 - writing pidfile to /var/run/uwsgi/uwsgi.pid Thu Feb 7 13:33:10 2013 - *** uWSGI is running in multiple interpreter mode *** Thu Feb 7 13:33:10 2013 - spawned uWSGI master process (pid: 29620) Thu Feb 7 13:33:10 2013 - *** PAUSE (press start to resume, if you do not have a joypad send SIGTSTP) *** Thu Feb 7 13:33:10 2013 - *** worker 2 suspended *** Thu Feb 7 13:33:10 2013 - *** worker 8 suspended *** Thu Feb 7 13:33:10 2013 - *** worker 5 suspended *** Thu Feb 7 13:33:10 2013 - *** worker 9 suspended *** Thu Feb 7 13:33:10 2013 - *** worker 4 suspended *** Thu Feb 7 13:33:10 2013 - *** worker 3 suspended *** Thu Feb 7 13:33:10 2013 - *** worker 10 suspended *** Thu Feb 7 13:33:10 2013 - *** worker 6 suspended *** Thu Feb 7 13:33:10 2013 - *** worker 1 suspended *** Thu Feb 7 13:33:10 2013 - *** worker 7 suspended *** Thu Feb 7 13:33:10 2013 - *** worker 12 suspended *** Thu Feb 7 13:33:10 2013 - *** worker 13 suspended *** Thu Feb 7 13:33:10 2013 - *** worker 16 suspended *** Thu Feb 7 13:33:10 2013 - *** worker 14 suspended *** Thu Feb 7 13:33:10 2013 - *** worker 11 suspended *** Thu Feb 7 13:33:10 2013 - *** psgix.harakiri.commit requested *** Thu Feb 7 13:33:10 2013 - ...The work of process 29294 is done. Seeya! Thu Feb 7 13:33:10 2013 - spawned uWSGI worker 1 (pid: 29622, cores: 1) Thu Feb 7 13:33:10 2013 - spawned uWSGI worker 2 (pid: 29627, cores: 1) Thu Feb 7 13:33:10 2013 - spawned uWSGI worker 3 (pid: 29628, cores: 1) Thu Feb 7 13:33:10 2013 - Respawned uWSGI worker 15 (new pid: 29632) Thu Feb 7 13:33:10 2013 - spawned uWSGI worker 4 (pid: 29633, cores: 1) Thu Feb 7 13:33:10 2013 - spawned uWSGI worker 5 (pid: 29635, cores: 1) Thu Feb 7 13:33:10 2013 - spawned uWSGI worker 6 (pid: 29636, cores: 1) Thu Feb 7 13:33:10 2013 - spawned uWSGI worker 7 (pid: 29637, cores: 1) Thu Feb 7 13:33:11 2013 - spawned uWSGI worker 8 (pid: 29642, cores: 1) Thu Feb 7 13:33:11 2013 - spawned uWSGI worker 9 (pid: 29643, cores: 1) Thu Feb 7 13:33:11 2013 - spawned uWSGI worker 10 (pid: 29644, cores: 1) Thu Feb 7 13:33:11 2013 - spawned uWSGI worker 11 (pid: 29649, cores: 1) Thu Feb 7 13:33:11 2013 - spawned uWSGI worker 12 (pid: 29650, cores: 1) Thu Feb 7 13:33:11 2013 - spawned uWSGI worker 13 (pid: 29651, cores: 1) Thu Feb 7 13:33:11 2013 - spawned uWSGI worker 14 (pid: 29652, cores: 1) Thu Feb 7 13:33:11 2013 - spawned uWSGI worker 15 (pid: 29657, cores: 1) Thu Feb 7 13:33:11 2013 - spawned uWSGI worker 16 (pid: 29658, cores: 1) Thu Feb 7 13:33:11 2013 - *** Zerg server enabled on /var/run/uwsgi/uwsgi.zerg *** Thu Feb 7 13:33:11 2013 - *** Stats server enabled on /var/run/uwsgi/uwsgi.stats fd: 227 *** Thu Feb 7 13:33:14 2013 - *** psgix.harakiri.commit requested *** What happens is this: - We have a running uWSGI - In Zerg dance we start new instance and pause the old one - We wait till all workers of the old instance are in either cheap or pause state: this is not always the case when frequent harakiri (triggered by the app) is involved (above example) Is it either possible to fix this in the code or I should be able to assume idle state is 'safe' after suspend/pause signal was sent to uWSGI master ? Regards, Marcin _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
