On Sat, Jun 15, 2013 at 10:02 PM, Roberto De Ioris <[email protected]> wrote:
> > > On Fri, Jun 14, 2013 at 9:27 PM, Roberto De Ioris <[email protected]> > > wrote: > > > >> > >> > >> I am not sure to understand what you mean, the stats server gives you > >> the > >> currently running connections. The problem is that with unix sockets you > >> do not have the listen queue size, but it should not be a big problem. > >> > > I meant that I cannot reproduce the problem artificially, so when it > > happens next time I will dump the stats server output. And the other one > > was that I cannot find with netstat or any other command, which process > is > > connecting to the unix socket, only the one which is listening. If it was > > TCP, "netstat -p" would show the pid of the client socket, as well as the > > server socket, but for unix sockets, only the listener pid is shown. > > > >> > > I have to admit, albeit faster (and more easy to secure), unix sockets are > pretty hard to debug (and they do not have listen queue monitoring). > >> if the harakiri is not triggering, well the problem could be much more > >> complex (like a db problem and so on). Are you sure all of the parts of > >> the app are gevent-friendly ? (pay attention to the db adapter as > >> generally they are the weak point). > >> > >> Well, I cannot be 100% sure, but as far as I know, yes. db is psycopg2 > > with "gevent_psycopg2" applied. Everything else involving network is > > pure-python. > > I believe, gdb or strace will show, if a problem is inside some other > > c-code. > > > a common error i have seen is not calling monkey patching on top. > > I do not know if it could be your case but recent releases have the > --gevent-monkey-patch option ensuring monkey patching happens as soon as > possible. > Yes, I definitely have monkey patching enabled, though not via --gevent-monkey-patch, but with python code in the beginning of the wsgi script. > > >> > > Can enabling the master help this? i.e. if the worker is stuck, the > master > > shouldn't, right? > > I had no "master = true" line in the ini file, but there are always 2 > > processes running for each ini file, so I'm not sure if the master was > > running. I now added "master = true" just in case it may help. > > yes it was running, but as you said background jobs are running, so your > instance is not stucked, it only looks like all of your uwsgi cores are > blocked waiting for something. > > You may have misunderstood me, the background jobs were NOT running, though usually they should. I have some cron-like functionality running inside gevent, and it stopped producing any logging output. Your idea about it the reason being the gevent loop blocked, is still a very good candidate for the right answer. Waiting for it to come again. The issue only occurred twice in a month, so I'll post here if it happens again. Thanks!
_______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
