Python Global Interpreter Lock (GIL)在Linux上使用taskset的多核系统上的解决方法？

Question

所以我刚刚看完这篇关于Python Global Interpreter Lock (GIL) http://blip.tv/file/2232410的演讲。

它的要点是，GIL是一个针对单核系统的非常好的设计(Python基本上将线程处理/调度留给了操作系统)。但这可能会在多核系统上产生严重的适得其反的效果，最终导致IO密集型线程被CPU密集型线程严重阻塞，上下文切换的开销，ctrl-C问题*等等。

所以，既然GIL限制我们基本上只能在一个CPU上执行Python程序，我想为什么不接受这一点，在Linux上简单地使用taskset来设置程序与系统上某个核心/cpu的亲和性(特别是在多核系统上运行多个Python应用程序的情况下)？

所以最终我的问题是:有没有人尝试过在Linux上将任务集与Python应用程序一起使用(特别是当在Linux系统上运行多个应用程序，以便多个核心可以与绑定到特定核心的一个或两个Python应用程序一起使用时)，如果有，结果是什么？这样做值得吗？对于某些工作负载，它是否会使情况变得更糟？我计划这样做，并对其进行测试(基本上是看看程序运行的时间是长还是短)，但我希望听到其他人关于你的经验。

另外: David Beazley (在链接视频中发表演讲的人)指出，一些C/C++扩展手动释放GIL锁，如果这些扩展针对多核(即科学或数字数据分析/等)进行了优化。那么，该扩展将被限制为单核，而不是从多核中获得数字处理的好处(因此可能会显着减慢您的程序)。另一方面，如果您没有使用像这样的扩展

我不使用多处理模块的原因是(在这种情况下)程序的一部分是严重的网络I/O限制(超文本传输协议请求)，所以有一个工作线程池是一个很好的方法来从盒子中挤压性能，因为一个线程发出超文本传输协议请求，然后由于它正在等待I/O，放弃了GIL，另一个线程可以做它的事情，所以程序的一部分可以很容易地运行100+线程，而不会对CPU造成太大的伤害，让我实际使用可用的网络带宽。至于stackless Python/etc，我对重写程序或替换我的Python堆栈不是很感兴趣(可用性也是一个问题)。

*只有主线程可以接收信号，所以如果你发送ctrl-C，Python解释器基本上会尝试让主线程运行，这样它就可以处理信号，但由于它不直接控制哪个线程正在运行(这留给操作系统)，它基本上会告诉操作系统不断切换线程，直到它最终到达主线程(如果你不走运，这可能需要一段时间)。

Answer 1

我从来没有听说过任何人在Python中使用taskset来提高性能。这并不意味着它不能在你的情况下发生，但一定要公布你的结果，这样其他人就可以批评你的基准测试方法并提供验证。

但就我个人而言，我会使用消息队列将I/O线程与CPU绑定的线程解耦。这样，您的前端现在完全是网络I/O绑定的(一些具有HTTP接口，一些具有消息队列接口)，并且非常适合您的线程化情况。那么CPU密集型进程既可以使用多进程，也可以只是等待工作到达消息队列的单个进程。

从长远来看，您可能还想考虑将线程I/O前端替换为Twisted或eventlets之类的东西，因为即使它们不会提高性能，它们也应该提高可伸缩性。您的后端现在已经是可伸缩的，因为您可以根据需要在任意数量的machines+cpus上运行消息队列。

Answer 2

另一种解决方案是：http://docs.python.org/library/multiprocessing.html

注意1: This is 不是Python语言的限制，而是CPython实现的限制。

注意2:关于亲和性，你的操作系统本身应该不会有问题。

Answer 3

一个有趣的解决方案是Ryan Kelly在他的博客上报告的实验：http://www.rfk.id.au/blog/entry/a-gil-adventure-threading2/

结果似乎非常令人满意。

​