greetings, I read somewhere that each zope thread acquires the global python interpreter lock before processing a request and until it releases it the other zope threads are essentially locked out. Does that mean zope threads are eventually serialized and there are no benefits to be gained from concurrent execution ? Any thoughts ? your ideas are much appreciated ty sathya
[sathya]
I read somewhere that each zope thread acquires the global python interpreter lock before processing a request and until it releases it the other zope threads are essentially locked out.
The Python GIL (global interpreter lock) affects all code written in Python: only one thread at a time can interpret Python bytecodes in a given process. That's true in or out of Zope.
Does that mean zope threads are eventually serialized and there are no benefits to be gained from concurrent execution ?
No. The GIL effectively serializes threads doing pure computation in Python, but many pieces of the Python implementation release the GIL around calls to known-threadsafe C libraries. The most important examples of that are I/O, of many kinds. For example, if a Python thread opens a socket, the GIL is released around the C-level code that does the low-level socket open, which allows other Python threads to proceed in parallel (of course the thread that does the C-level socket open waits for the latter to finish; it reacquires the GIL after the socket operation is complete and it's ready to go back to interpreting Python bytecodes). Because Zope does a lot of network I/O, this form of parallelism can be very useful for it.
Tim Peters wrote: tim thanks much for the explanation. some points below.
[sathya]
I read somewhere that each zope thread acquires the global python interpreter lock before processing a request and until it releases it the other zope threads are essentially locked out.
[tim]
No. The GIL effectively serializes threads doing pure computation in Python, but many pieces of the Python implementation release the GIL around calls to known-threadsafe C libraries. The most important examples of that are I/O, of many kinds. For example, if a Python thread opens a socket, the GIL is released around the C-level code that does the low-level socket open, which allows other Python threads to proceed in parallel (of course the thread that does the C-level socket open waits for the latter to finish; it reacquires the GIL after the socket operation is complete and it's ready to go back to interpreting Python bytecodes). Because Zope does a lot of network I/O, this form of parallelism can be very useful for it.
[sathya] great ! If I understand correctly, if we had a zope process running on an smp linux machine and doing lots of RDBMS calls we would not be limited by the GIL. In essence threads running on multiple cpus would probably not have to wait on acquiring the GIL as most every page request results in a ZSQL method call which in turn would release the GIL. Therefore SMP may not be hindered by the GIL. That said , since ZEO ends up doing multiple python interpreters its possibly the more reliable approach to take advantage of SMP linux. please point out any flaws in my thought process ..... again thanks very much for putting it in persepective. it clears up some fog for us ! regards sathya
On Wed, 2004-04-28 at 03:41, sathya wrote:
[sathya] great ! If I understand correctly, if we had a zope process running on an smp linux machine and doing lots of RDBMS calls we would not be limited by the GIL. In essence threads running on multiple cpus would probably not have to wait on acquiring the GIL as most every page request results in a ZSQL method call which in turn would release the GIL. Therefore SMP may not be hindered by the GIL. That said , since ZEO ends up doing multiple python interpreters its possibly the more reliable approach to take advantage of SMP linux. please point out any flaws in my thought process .....
SMP is not doing any good for you when not running multiple Python processes. The GIL doesn't work per CPU but for the whole system. You very likely will end up locking your CPUs 2-n on a N-way system due to the GIL. ZEO actually does the trick, but you should use CPU binding for the processes to make sure they won't affect other processors. Cheers, Christian
[christian]
That said , since ZEO ends up doing multiple python interpreters its possibly the more reliable approach to take advantage of SMP linux. please point out any flaws in my thought process .....
SMP is not doing any good for you when not running multiple Python processes. The GIL doesn't work per CPU but for the whole system. You very likely will end up locking your CPUs 2-n on a N-way system due to the GIL.
I would think the GIL is relevant per process and not the whole system. If I ran multiple python processes on a N-way system they would not deadlock on the GIL as they dont contend for the same GIL.
ZEO actually does the trick, but you should use CPU binding for the processes to make sure they won't affect other processors.
What about threads on linux ? will binding a process to a CPU also mean all threads spawned by the process are also bound to the same processor ? I am not aware of linux support for binding threads to a CPU so I guess it does not matter . Further if extension modules such as RDBMS adapters do not cause the GIL to be freed up ,If I understand tim correctly any calls to only "known" thread safe APIS will cause the GIL to be unlocked. So python applications using thread safe implementations of MySQL db api will still suffer from the GIL bottleneck. bummer. time to deploy ZEO or hack the db adapter to be GIL aware ? I wonder if there is a way to inform python about thread safe api calls so that it can release the GIL thanks much for this discussion regards sathya
Cheers, Christian
sathya wrote:
What about threads on linux ? will binding a process to a CPU also mean all threads spawned by the process are also bound to the same processor ? I am not aware of linux support for binding threads to a CPU so I guess it does not matter .
For a full discussion of this and oter SMP issues, see this article on Zope org. http://www.zope.org/Members/glpb/solaris/multiproc It is possible to do CPU-affinity on Linux, and nowadyas there are even userspace tools that do this. http://www.hpl.hp.com/research/linux/kernel/o1-openmp.php http://www.tech9.net/rml/ http://kerneltrap.org/node/view/335 CPU.-affinity is avilable in RH 3.0 per default, and the same tools are avialable as a set of patches for various kernel versions. *In general, on an SMP box, Python processes MUST be bound to any one of the CPUs on a amchine* Not the same CPU, but each python process has to stay on the same CPU all the time. As I understand it. the GIL is not a problem *at all* unless you happen to run on smp machines. There are ofcourse optimisations to when and where to relase the GIL, but in general python takes care of that all by itself. ZEO won't save you from the GIL - ZEO will allow you to scale your Zope beyond the constraints of 1 singel zope process for serving the same content. ZEO implements storage of the data Zope serves in one centralised location (the ZEO storage server) and allows several Zope processes (acting as ZEO clients) to serve/update the same content. These Zope processes can ofcourse be placed in a kluster, each ZEO client in a different machine. /dario -- -- ------------------------------------------------------------------- Dario Lopez-Kästen, IT Systems & Services Chalmers University of Tech.
Dario Lopez-Kästen wrote: thanks much for the info. turns out that the updated kernel rpms for RH8 and RH 9 2.4.20-28.8smp contain the patch for cpu affinity as well at this point seems like a good idea to deploy ZEO and bind each client to a processor and test it out ,hopefully with a 4way smp we should see 4X improvement in performance !!! (We hope ) one other point [dario]
As I understand it. the GIL is not a problem *at all* unless you happen to run on smp machines. There are ofcourse >optimisations to when and where to relase >the GIL, but in general python takes care of that all by itself. How about when you use extension modules that python does not have apriori knowledge about (it only optimizes when it encounters known "threadsafe" api calls like the ones in clib or socket lib ). So, as I understand it if a python database module invokes a native library call python will not yeild the GIL. So if your zope app is making heavy use of an RDBMS we would still see zope threads waiting on the GIL until the long running thread fetched DB results and performed network IO to send back the response at which point the GIL would be released. Some GIL aware extesnion modules such as the mxodbc DA from egenix free the GIL for query API (http://www.egenix.com/mailman-archives/egenix-users/2003-February/000200.htm...).
That said it is clear that using ZEO and CPU affinity guarantees the best utilization of SMP for your zope app Thanks tim ,dario and christian .... regards sathya
sathya wrote:
What about threads on linux ? will binding a process to a CPU also mean all threads spawned by the process are also bound to the same processor ? I am not aware of linux support for binding threads to a CPU so I guess it does not matter .
For a full discussion of this and oter SMP issues, see this article on Zope org.
http://www.zope.org/Members/glpb/solaris/multiproc
It is possible to do CPU-affinity on Linux, and nowadyas there are even userspace tools that do this.
http://www.hpl.hp.com/research/linux/kernel/o1-openmp.php
http://kerneltrap.org/node/view/335
CPU.-affinity is avilable in RH 3.0 per default, and the same tools are avialable as a set of patches for various kernel versions.
*In general, on an SMP box, Python processes MUST be bound to any one of the CPUs on a amchine* Not the same CPU, but each python process has to stay on the same CPU all the time.
As I understand it. the GIL is not a problem *at all* unless you happen to run on smp machines. There are ofcourse optimisations to when and where to relase the GIL, but in general python takes care of that all by itself.
ZEO won't save you from the GIL - ZEO will allow you to scale your Zope beyond the constraints of 1 singel zope process for serving the same content.
ZEO implements storage of the data Zope serves in one centralised location (the ZEO storage server) and allows several Zope processes (acting as ZEO clients) to serve/update the same content. These Zope processes can ofcourse be placed in a kluster, each ZEO client in a different machine.
/dario
participants (4)
-
Christian Theune -
Dario Lopez-Kästen -
sathya -
Tim Peters