> Hi Roberto, > > On Thu, 31 Jan 2013 20:24:00 +0100 > "Roberto De Ioris" <[email protected]> wrote: > >> Just to announce that both uWSGI 1.4 (the tree on github) and 1.5 have >> the --thunder-lock option to force an "apache style" accept() usage. >> >> It is strongly advised to use that ONLY if you know what you are >> doing and ONLY on linux as its robust locking system looks the most >> (only ?) reliable one. > > Just gave it a shot and I see requests are being distributed now more > equally although I still see some workers which are idle for quite some > time without any request.. eg. > > "id":16, > "pid":6391, > "requests":5942, > "delta_requests":1, > "exceptions":0, > "harakiri_count":0, > "signals":0, > "signal_queue":0, > "status":"idle", > "rss":0, > "vsz":0, > "running_time":1930514110, > "last_spawn":1360851106, > "respawn_count":16, > "tx":106593421, > "avg_rt":69553, > > # date +%s > 1360851573 > > which means 1 request in 1360851573-1360851106=476s (machine is constantly > getting > new requests). I see that occasionally certain workers get "stuck" and do > not handle > any new requests when idle whereas others are happily moving there request > counters > forward. Is this an expected behaviour ? > >
I suppose ipc semaphores (the one used by apache) are more predictable, while pthread robust mutexes tend to favourite kernel scheduling choices (resulting in potential better performance). Hard to say :) You can try (just for fun) adding --lock-engine ipcsem Let me know -- Roberto De Ioris http://unbit.it _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
