最近发现公司的scrapy爬虫服务运行起来之后,占用内存持续增大,单个爬虫爬取几十万网页之后,占用内存达到1,2个G,单台服务器运行10个以上的爬虫时,很快就把服务器内存耗尽了。于是着手对爬虫进行空间性能分析及优化
首先分析以下可能原因,并依次进行排查:
- 内存泄露
- 资源长时间占用无法释放
- 队列堵塞
排查及修改记录:
1)引用赋值带来的资源无法释放
python带有自动的垃圾回收机制,用户不需要主动的释放对象空间,因此暂不考虑内存泄露问题。更多的内存问题出现在对象交叉引用或者多层引用后,无法自动释放的情况。于是仔细排查代码,发现了以下问题:
class WangdingSpider(scrapy.Spider):
# 无用代码忽略...
def parse_page(self, response):
meta = response.meta
meta['source'] = response.url
...
# 提取新的链接 -> newlinks
for link in newlinks:
yield Request(link, meta=meta, callback=self.parse_page)
生成一个新请求时,会传递一组元数据meta。代码直接由当前response的meta数据直接赋值后传入新的请求中,这就带来一个潜在的内存问题:python的赋值是传递引用,也就是等号两边变量指向同一个对象(同一个地址),meta继续通过request向下传递时,原来的response对象由于一部分成员被新的request引用而无法释放,随着请求越来越多,内存持续增大。
要解决这个问题,需要将赋值改成拷贝,查看meta的实际数据结构发现其中的value都是简单类型,因此直接采用浅拷贝即可(关于python 的深拷贝、浅拷贝参考https://docs.python.org/2/library/copy.html)。这样新的meta变量与response.meta不再指向同一对象,过期对象的资源可以自动回收
import copy
class WangdingSpider(scrapy.Spider):
# 无用代码忽略...
def parse_page(self, response):
meta = copy.copy(response.meta)
meta['source'] = response.url
...
# 提取新的链接 -> newlinks
for link in newlinks:
yield Request(link, meta=meta, callback=self.parse_page)
2)scrapy的请求过多
利用scrapy自带的telnet工具,可以查看scrapy的一些运行时参数
telnet localhost 6023
进入telnet后输入prefs(),查看当前的对象数
>>> prefs()
Live References
HtmlResponse 75 oldest: 5s ago
PageItem 11 oldest: 0s ago
Request 146609 oldest: 12408s ago
Selector 67 oldest: 4s ago
WangdingSpider 1 oldest: 31198s ago
在爬虫占用内存达到1.2G的时候,内存中的request有14万多,查看scrapy的官方文档,发现其中一章提供了可以将request队列写入硬盘的方法https://doc.scrapy.org/en/latest/topics/jobs.html?highlight=JOBDIR,这个技术的初衷是可以让爬虫中断后恢复现场继续运行,但是也可以减少内存的占用。
重新启动scrapy,按照文档说明传入jobdir参数,
harper@ubuntu-server: scrapy crawl wdcrawler -s JOBDIR=/data/jobdir
运行一段时间后检查内存,发现scrapy始终只占用100~200MB,而jobdir中的request文件越来越大,说明scrapy把之前内存中保存的大量request对象存到了文件中。
总结:
本次scrapy空间性能优化主要完成两个工作:
1)利用copy解决python对象嵌套引用问题,使资源能顺利释放
2)将scrapy的请求队列存入文件,省掉其在内存中的占用空间