我需要发出100k头请求,并且我在请求之上使用gevent.我的代码运行了一段时间,但最终挂起.我不知道为什么它会挂起,或者它是否挂在请求或gevent中.我在请求和gevent中都使用了timeout参数.
请看下面的我的代码片段,让我知道我应该改变什么.
import gevent
from gevent import monkey, pool
monkey.patch_all()
import requests
def get_head(url, timeout=3):
try:
return requests.head(url, allow_redirects=True, timeout=timeout)
except:
return None
def expand_short_urls(short_urls, chunk_size=100, timeout=60*5):
chunk_list = lambda l, n: ( l[i:i+n] for i in range(0, len(l), n) )
p = pool.Pool(chunk_size)
print 'Expanding %d short_urls' % len(short_urls)
results = {}
for i, _short_urls_chunked in enumerate(chunk_list(short_urls, chunk_size)):
print '\t%d. processing %d urls @ %s' % (i, chunk_size, str(datetime.datetime.now()))
jobs = [p.spawn(get_head, _short_url) for _short_url in _short_urls_chunked]
gevent.joinall(jobs, timeout=timeout)
results.update({_short_url:job.get().url for _short_url, job in zip(_short_urls_chunked, jobs) if job.get() is not None and job.get().status_code==200})
return results
我已经尝试过grequest,但它已经被放弃了,我已经完成了github pull请求,但它们都有问题.
解决方法:
您正在观察的RAM使用量主要来自存储100.000响应对象时堆积的所有数据以及所有底层开销.我已经复制了你的应用案例,并从*Alexa排名中解除了对15000个URL的HEAD请求.这并不重要
>我是否使用gevent Pool(即每个连接一个greenlet)或一组固定的greenlet,都请求多个URL
>我设置池大小有多大
最终,RAM使用量随着时间的推移而增长,达到相当大的水平.但是,我注意到从请求更改为urllib2已导致RAM使用量减少约2倍.也就是说,我换了
result = requests.head(url)
同
request = urllib2.Request(url)
request.get_method = lambda : 'HEAD'
result = urllib2.urlopen(request)
其他一些建议:不要使用两种超时机制. Gevent的超时方法非常可靠,你可以像这样轻松使用它:
def gethead(url):
result = None
try:
with Timeout(5, False):
result = requests.head(url)
except Exception as e:
result = e
return result
可能看起来很棘手,但要么返回None(在非常精确的5秒之后,并指示超时),任何表示通信错误或响应的异常对象.效果很好!
虽然这可能不是问题的一部分,但在这种情况下,我建议让工人保持活力,让他们分别处理多个项目!实际上,产生greenlets的开销很小.尽管如此,这将是一个非常简单的解决方案,包含一组长寿命的greenlets:
def qworker(qin, qout):
while True:
try:
qout.put(gethead(qin.get(block=False)))
except Empty:
break
qin = Queue()
qout = Queue()
for url in urls:
qin.put(url)
workers = [spawn(qworker, qin, qout) for i in xrange(POOLSIZE)]
joinall(workers)
returnvalues = [qout.get() for _ in xrange(len(urls))]
此外,你真的需要意识到这是你正在解决的大规模问题,产生非标准问题.当我再现你的场景时,超时20秒,要求100个工作人员和15000个URL,我很容易得到大量的套接字:
# netstat -tpn | wc -l
10074
也就是说,操作系统有超过10000个套接字要管理,其中大部分都处于TIME_WAIT状态.我还观察到“打开文件太多”错误,并通过sysctl调整了限制.当您请求100.000个URL时,您可能也会达到这样的限制,并且您需要采取措施来防止系统挨饿.
还要注意您使用请求的方式,它会自动跟踪从HTTP到HTTPS的重定向,并自动验证证书,所有这些都肯定会花费RAM.
在我的测量中,当我将所请求的URL的数量除以程序的运行时间时,我几乎从未传递100个响应/秒,这是全世界与外部服务器的高延迟连接的结果.我猜你也受这种限制的影响.将架构的其余部分调整到此限制,您可能能够生成从Internet到磁盘(或数据库)的数据流,其间的RAM使用量不是很大.
我应该解决你的两个主要问题,具体来说:
我认为gevent /你使用它的方式不是你的问题.我认为你只是低估了你的任务的复杂性.它伴随着令人讨厌的问题,并将您的系统推向极限.
>您的RAM使用问题:如果可以,请使用urllib2开始.然后,如果事情积累仍然太高,你需要反对积累.尝试生成稳定状态:您可能希望开始将数据写入磁盘,并且通常可以解决对象可能变为垃圾回收的情况.
>你的代码“最终挂起”:可能这是你的RAM问题.如果不是,那么不要产生这么多的greenlets,而是按照指示重用它们.此外,进一步降低并发性,监控打开的套接字数量,必要时增加系统限制,并尝试找出软件挂起的确切位置.