为什么多线程python程序在ec2微实例上运行缓慢? [英] Why multi-threaded python program slow on ec2 micro-instance?

问题描述

我正在使用Online Judge代码检查器.我的代码在python 2.7中使用多线程.我本地计算机上的同一程序(i核心3 RAM 4GB)在1分钟10秒内评估了大约1000个子组件.但是，当我在ec2微型实例(大约600 MB RAM)上运行它时，大约需要40分钟(随机变慢了几秒钟).要知道我把东西弄坏的原因.

I am working on a Online Judge code checker.My code uses multi-threading in python 2.7.The same program on my local machine (i core 3 RAM 4GB) evaluates about 1000 submisions in 1 minute 10 seconds. But when I run it on ec2 micro instance(about 600 MB RAM) it takes about 40 minutes(It gets slow for some random seconds).To know the reason I broke down things.

1. 首先，这是我的评估者的工作方式:
   

1. First this is how my evaluator works:
   

• 我有一个主程序 worker.py ，它创建了多个线程
• 主线程(暂时)从文件中提取提交(一次10个)并将其放入全局队列中
• 侧线程从队列中提取(一个提交仅由一个线程评估)
• 边线程提交后，将其发送到函数 compile ，该函数将提交的可执行文件返回到该线程
• 然后线程将该可执行文件发送到运行该可执行文件的函数 run (使用具有定义的内存和时间限制的沙箱)并将可执行文件的输出写入文件，然后对其进行检查
  针对标准输出
• 在队列变空之后，主线程再次提取10个提交并将其放入队列中
  
  

• I have a main program worker.py , which creates multiple threads
• The main thread pulls submissions(10 at a time) from a file(for time being) and puts them in a global queue
• The side threads take submisions from queue(one submission evaluated solely by one thread)
• After a side thread takes a submission it sends it to a function compile,which returns the executable of submission back to that thread
• Then the thread sends this executable to a function run which runs the executable (using sandbox with defined memory and time limits) and writes the output of the executable to file and then checks it
  against standard output
• After the queue gets empty the main thread again pulls 10 submissions and places them in queue
  
  

函数 compile 和 run :

• 编译功能和运行功能将可执行文件和输出保存在名为(分别)的文件中像< thread_Name> .exe 和< thread_Name> .txt 而且没有覆盖的问题.
• 仅当来自编译功能的状态为OK(已编译的文件)时，线程才会运行功能，否则将引发编译错误.该提交
  
  

• The compile function and run function save the executable and output in files(repectively) named like <thread_Name>.exe and <thread_Name>.txt so that every thread has its own files and there is no issue of overwriting.
• A thread goes to run function only if status from compile function was OK(the file compiled)otherwise throws compile error for that submission
  
  

现在我有疑问:

• 是由于ec2上的资源不足或由于到期而导致的执行速度慢的问题python的多线程.在我的脚本中，线程可以访问全局变量例如正在运行的队列(我放了锁)和 test.py(我没有放过锁)函数按字符逐个检查标准输出的输出(类似于vimdiff)，和 mysandbox.py(沙箱的libsandbox)以及其他一些全局变量.由于python的GIL导致工作缓慢也是如此.是这样，为什么它在我的本地计算机上可以快速运行.
• 暂时也给我相同的文件 test.cpp(两个数字相加并打印结果)1000次.因此，当我故意在此文件中产生编译错误并运行我的main程序在ec2上运行非常快.据此，我推断出编译和和我的程序的运行(编译和运行功能)花费主要时间，而不是线程创建和管理.

• Is the problem of slow execution on ec2 due to the resources it has or due to multi-threading of python.In my scripts the threads to access global variables such as the queue(i put locks) and test.py(I dont put lock on it) which in run function checks the output with standard output character by character(vimdiff like), and mysandbox.py(libsandbox the sandbox) and some other global variables.So is the slow working due to GIL of python.If it is so then why does it work fast on my local machine.
• Also for time being I give the same file test.cpp(adds two numbers and prints result) 1000 times.So when I purposely make a compile error in this file and run my main program on ec2 it runs pretty fast.From that I deduced that the compiling and and running(compile and run functions) of my program take the main time,not the thread creation and management.

我知道这是一个很大的问题，但是任何帮助都非常感激(否则我将押注我所有的声誉来悬赏它:)).

I know its a vast question but any help is really appreciated(or i will have to keep bounty on it betting all my reputation :) ).

推荐答案

微实例对于持续的计算任务(通过设计)变得非常慢.

Micro instances become extremely slow for sustained computational tasks (by design).

您将代码编写为多线程的，以利用整个计算机"的CPU资源来执行文件检索和编译之类的任务，这是提高性能的好方法.

You wrote your code to be multi-threaded to take advantage of the entire "machine's" CPU resources for tasks like file retrieval and compilation, which is good practice for performance.

虽然这在您已保证配置硬件资源的物理机或虚拟机上很有意义，但由于亚马逊分配资源的方式在微型实例上没有意义

And while this makes sense on a physical machine or a virtual machines where you have guaranteed provisioned hardware resources, it doesn't makes sense on a micro instance due to the way resources are allocated by Amazon.

根据Amazon的文档，微型实例仅设计用于突发CPU操作，因此，如果您尝试使用占用CPU使用率的多个线程，则会遇到Amazon自身施加的巨大瓶颈:

Per Amazon's documentation, micro instances are designed for short-burst CPU operations only and will therefore experience huge bottlenecks imposed by Amazon itself if you try to use multiple threads that eat CPU usage:

如果应用程序消耗的资源超过了您实例分配的CPU资源，我们会暂时限制该实例，使其在较低的CPU级别上运行.如果您的实例继续使用其所有分配的资源，其性能将下降.我们将增加限制其CPU级别的时间，从而增加允许实例再次爆发之前的时间.

If the application consumes more than your instance's allotted CPU resources, we temporarily limit the instance so it operates at a low CPU level. If your instance continues to use all of its allotted resources, its performance will degrade. We will increase the time that we limit its CPU level, thus increasing the time before the instance is allowed to burst again.

查看我刚刚链接的文档中的CPU使用率图，以获取更多详细信息.

Take a look at the CPU usage graphs in the documentation I just linked to to get more details.

要证明这是问题所在，您可以直接启动一个小实例并在其中运行判断软件-您应该体验到与台式机类似的显着改进.

To prove that this is the issue, you could simply launch a small instance instead and run your judge software there - you should experience a dramatic improvement similar to your desktop machine.

TL; DR当尝试在微型实例上使用持久性CPU时，它的功能可能不如旧的Palm Treo.

这篇关于为什么多线程python程序在ec2微实例上运行缓慢?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！