-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dario Lopez-Kästen wrote: <snip>
Let me be the first to admit my total lack of knowledge of kernel task schedulers, but generally speaking, unless the scheduler makes sure that a threaded python process never ever gets distributed over two processors simultaniously, then the GIL *will* be an issue.
The hypothesis is that the scheduler "notices" that threads in a single Python process are always blocking on a single kernel resource (the semaphore / mutex which is the GIL), and hence migrates them all to the same CPU (over time). I could imagine that this is like the "hand-rolled assembly vs. compiler-generated code" case: older kernels (like the one your old app was dpeloyed atop, perhaps?) didn't have such smarts, but newsr ones do.
In any event, I'd love to be proved wrong about the need for taskset (especially if someone comes up with measurable data to that effect) because it means that my sysadmins can simplify their setup for managing Zope (making Zope even more acceptable :-).
WHile at ZC, one of the other engineers and I did some testing on SMB boxes, and found that "one appserver per CPU" gave us near linear scaling of the application, without any explicit affinity set. I don't have the numbers (we were using stock Dell 1U dual CPU boxes, I think), but the win seemed clear enough that we quit invesigating taskset. Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEIVAK+gerLs4ltQ4RAnb9AKC7qw38+BqNdAbY79bqPR4/G7USCwCbBmit UX+GcftjNQ5fUKajALsEbSk= =+E5c -----END PGP SIGNATURE-----