最近发现公司的scrapy爬虫服务运行起来之后，占用内存持续增大，单个爬虫爬取几十万网页之后，占用内存达到1,2个G，单台服务器运行10个以上的爬虫时，很快就把服务器内存耗尽了。于是着手对爬虫进行空间性能分析及优化
首先分析以下可能原因，并依次进行排查：
- 内存泄露
- 资源长时间占用无法释放
- 队列堵塞
排查及修改记录：
1）引用赋值带来的资源无法释放
python带有自动的垃圾回收机制，用户不需要主动的释放对象空间，因此暂不考虑内存泄露问题。更多的内存问题出现在对象交叉引用或者多层引用后，无法自动释放的情况。于是仔细排查代码，发现了以下问题：
class BLSpider(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 BLSpider(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参数，
scrapy crawl news -s JOBDIR=/data/jobdir
运行一段时间后检查内存，发现scrapy始终只占用100~200MB，而jobdir中的request文件越来越大，说明scrapy把之前内存中保存的大量request对象存到了文件中。
总结：
本次scrapy空间性能优化主要完成两个工作：
1）利用copy解决python对象嵌套引用问题，使资源能顺利释放
2）将scrapy的请求队列存入文件，省掉其在内存中的占用空间