Dnia piątek, 24 sierpnia 2012 17:52:31 Roberto De Ioris pisze: > > Hi, > > > > is there anything like --reload-mercy but for declaring maximum time > > app startup is allowed to take? > > I had an issue with one ruby app, it load gem at startup and this gem > > connects to database that go overloaded, connection to that db hanged > > and blocked app startup. > > I think that uWSGI don't show any logs until app is loaded or failed > > to load, but in this case it didn't showed anything making the issue > > less easy to debug. > > Startup time limit would help that since I would have information > > where the issue is located. > > I think that most helpful would be to have: > > * uWSGI startup logging might be improved to dump current messages > > after a while, even if we are still starting the app, I think that > > right now messages are written to buffer and pushed using proper > > logger plugin after app is fully loaded > > * time limit for app startup, if app is taking longer to start then > > kill it and start over, traceback of what app was doing would be great > > and it should be easy since uWSGI already supports that > > > > Is any of the above possible right now? If not, can it be implemented? > > Some ideas: > > 1.3 Emperor has the concept of heartbeat (pass heartbeat = <n> to vassals) > > Each vassal sends heartbeat at the specified frequency, if the emperor > does not receive them the vassal is considered 'unloyal' and a reload > message is sent. We can work on that area, implementing an emperor message > for "printing" backtrace, when no heartbeat is sent in time.
This is better but I would it tell us that worker is loading too much, or just that it's unloyal to some undefined reason (since emperor doesn't know what worker is doing). But maybe it could be extended: 1. worker is going to be started/reloaded 2. workers sends signal to empreror saying "hey, i'm going to restart now" 3. emeperor marks worker as starting 4. if emperor doesn't receive heartbeat in <some time limit in seconds> since worker startup than we know it's startup issue and can log proper message If we had bidirectional messanging vassla<->emperor, than we could make emperor more aware of what is going on with vassals. it might be helpfull. Does it sound like a good idea? Or maybe it's already possible? uWSGI has so many features I still find myself amazed ;) > Backtrace is implemented only for python apps, so (as an example) ruby > apps would only get c backtrace. Information that something is wrong is important, level of detail of such information is second in priority. C backtrace is good enough. With my issue I had to run strace on starting worker to check whats going on, this way I've noticed that ruby is loading gem file, gem is opening connection and next I had a buch of timeout messages. But this was after I've looked at many other things without any luck. If I had normal uWSGI startup messages in logs with additional information that worker is taking too long to start, then it would help me concentrate on debugging app startup. It's corner case issue, it's rare, we can't protect from all such issues in advance, but we should learn from them. Łukasz Mierzwa _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
