[Python-Dev] Improved thread switching

[Adam Olsen]

On Tue, Mar 18, 2008 at 1:29 AM, Stefan Ring <s.r at visotech.at> wrote:
> The company I work for has over the last couple of years created an
>  application server for use in most of our customer projects. It embeds Python
>  and most project code is written in Python by now. It is quite resource-hungry
>  (several GB of RAM, MySQL databases of 50-100GB). And of course it is
>  multi-threaded and, at least originally, we hoped to make it utilize multiple
>  processor cores. Which, as we all know, doesn't sit very well with Python. Our
>  application runs heavy background calculations most of the time (in Python)
>  and has to service multiple (few) GUI clients at the same time, also using
>  Python. The problem was that a single background thread would increase the
>  response time of the client threads by a factor of 10 or (usually) more.
>
>  This led me to add a dirty hack to the Python core to make it switch threads
>  more frequently. While this hack greatly improved response time for the GUI
>  clients, it also slowed down the background threads quite a bit. top would
>  often show significantly less CPU usage -- 80% instead of the more usual 100%.
>
>  The problem with thread switching in Python is that the global semaphore used
>  for the GIL is regularly released and immediately reacquired. Unfortunately,
>  most of the time this leads to the very same thread winning the race on the
>  semaphore again and thus more wait time for the other threads. This is where
>  my dirty patch intervened and just did a nanosleep() for a short amount of
>  time (I used 1000 nsecs).

Can you try with a call to sched_yield(), rather than nanosleep()?  It
should have the same benefit but without as much performance hit.

If it works, but is still too much hit, try tuning the checkinterval
to see if you can find an acceptable throughput/responsiveness
balance.

-- 
Adam Olsen, aka Rhamphoryncus