调试内存泄漏¶
在Scrapy中，诸如请求、响应和项目等对象具有有限的生命周期：它们被创建，使用一段时间，最后被销毁。
从所有这些对象中，Request 可能是生命周期最长的一个，因为它会一直等待在 Scheduler 队列中，直到处理它的时间到来。更多信息请参见 架构概述。
由于这些Scrapy对象具有（相当长的）生命周期，始终存在在内存中累积它们而没有正确释放它们的风险，从而导致所谓的“内存泄漏”。
为了帮助调试内存泄漏，Scrapy 提供了一个内置机制来跟踪对象引用，称为 trackref，你也可以使用一个名为 muppy 的第三方库进行更高级的内存调试（更多信息见下文）。这两种机制都必须从 Telnet Console 中使用。
内存泄漏的常见原因¶
Scrapy开发者经常（有时是偶然，有时是故意）传递在请求中引用的对象（例如，使用cb_kwargs或meta属性或请求回调函数），这实际上将这些引用对象的生命周期绑定到请求的生命周期。这是迄今为止Scrapy项目中最常见的内存泄漏原因，对于新手来说也是一个相当难以调试的问题。
在大型项目中，爬虫通常由不同的人编写，其中一些爬虫可能会“泄漏”，从而在并发运行时影响其他（编写良好的）爬虫，这反过来又会影响整个爬取过程。
泄漏也可能来自您编写的自定义中间件、管道或扩展，如果您没有正确释放（先前分配的）资源。例如，在spider_opened上分配资源但在spider_closed上不释放它们，如果您正在运行每个进程多个蜘蛛，可能会导致问题。
请求过多？¶
默认情况下，Scrapy 将请求队列保存在内存中；它包括
Request 对象和所有在 Request 属性中引用的对象
（例如在 cb_kwargs
和 meta 中）。
虽然这不一定是内存泄漏，但这可能会占用大量内存。启用
持久化作业队列 可以帮助控制内存使用。
使用trackref调试内存泄漏¶
trackref 是 Scrapy 提供的一个模块，用于调试最常见的内存泄漏情况。它基本上跟踪所有活动的 Request、Response、Item、Spider 和 Selector 对象的引用。
您可以进入telnet控制台，并使用prefs()函数检查当前有多少对象（上述类别的）是活跃的，该函数是print_live_refs()函数的别名：
telnet localhost 6023
.. code-block:: pycon
>>> prefs()
Live References
ExampleSpider 1 oldest: 15s ago
HtmlResponse 10 oldest: 1s ago
Selector 2 oldest: 0s ago
FormRequest 878 oldest: 7s ago
如你所见，该报告还显示了每个类中最旧对象的“年龄”。如果你在每个进程中运行多个爬虫，很可能通过查看最旧的请求或响应来找出哪个爬虫在泄漏。你可以使用get_oldest()函数（从telnet控制台）获取每个类中最旧的对象。
哪些对象被跟踪？¶
由trackrefs跟踪的对象都来自这些类（及其所有子类）：
scrapy.Requestscrapy.Selector
一个真实的例子¶
让我们看一个假设的内存泄漏案例的具体例子。 假设我们有一些蜘蛛，其中有一行类似于这样的代码：
return Request(f"http://www.somenastyspider.com/product.php?pid={product_id}",
callback=self.parse, cb_kwargs={'referer': response})
该行代码在请求中传递了一个响应引用，这实际上将响应的生命周期与请求的生命周期绑定在一起，这肯定会导致内存泄漏。
让我们看看如何通过使用trackref工具来发现原因（当然，事先并不知道）。
爬虫运行几分钟后，我们注意到其内存使用量增长了很多，我们可以进入其telnet控制台并检查实时引用：
>>> prefs()
Live References
SomenastySpider 1 oldest: 15s ago
HtmlResponse 3890 oldest: 265s ago
Selector 2 oldest: 0s ago
Request 3878 oldest: 250s ago
有如此多的实时响应（而且它们如此古老）确实令人怀疑，因为与请求相比，响应应该具有相对较短的寿命。响应的数量与请求的数量相似，所以看起来它们以某种方式联系在一起。我们现在可以去检查蜘蛛的代码，找出生成泄漏的那行讨厌的代码（在请求中传递响应引用）。
有时关于活动对象的额外信息可能会有所帮助。 让我们检查最旧的响应：
>>> from scrapy.utils.trackref import get_oldest
>>> r = get_oldest("HtmlResponse")
>>> r.url
'http://www.somenastyspider.com/product.php?pid=123'
如果你想遍历所有对象，而不是获取最旧的对象，你可以使用 scrapy.utils.trackref.iter_all() 函数：
>>> from scrapy.utils.trackref import iter_all
>>> [r.url for r in iter_all("HtmlResponse")]
['http://www.somenastyspider.com/product.php?pid=123',
'http://www.somenastyspider.com/product.php?pid=584',
...]
蜘蛛太多了吗？¶
如果你的项目中有太多并行执行的爬虫，
prefs() 的输出可能会难以阅读。
因此，该函数有一个 ignore 参数，可以用来
忽略特定的类（及其所有子类）。例如，这将不会显示任何对爬虫的实时引用：
>>> from scrapy.spiders import Spider
>>> prefs(ignore=Spider)
scrapy.utils.trackref 模块¶
以下是trackref模块中可用的函数。
- scrapy.utils.trackref.get_oldest(class_name)[source]¶
返回具有给定类名的最旧的活动对象，如果未找到则返回
None。首先使用print_live_refs()获取每个类名所有跟踪的活动对象的列表。
- scrapy.utils.trackref.iter_all(class_name)[source]¶
返回一个迭代器，遍历所有具有给定类名的存活对象，如果未找到则返回
None。首先使用print_live_refs()获取按类名分类的所有跟踪存活对象的列表。
使用muppy调试内存泄漏¶
trackref 提供了一个非常方便的机制来追踪内存泄漏，但它只跟踪那些更可能引起内存泄漏的对象。然而，还有其他情况下，内存泄漏可能来自其他（或多或少不太明显的）对象。如果这是你的情况，并且你无法使用 trackref 找到泄漏，你还有另一个资源：muppy 库。
你可以使用来自Pympler的muppy。
如果您使用 pip，您可以使用以下命令安装 muppy：
pip install Pympler
这是一个使用 muppy 查看堆中所有可用 Python 对象的示例：
>>> from pympler import muppy
>>> all_objects = muppy.get_objects()
>>> len(all_objects)
28667
>>> from pympler import summary
>>> suml = summary.summarize(all_objects)
>>> summary.print_(suml)
types | # objects | total size
==================================== | =========== | ============
<class 'str | 9822 | 1.10 MB
<class 'dict | 1658 | 856.62 KB
<class 'type | 436 | 443.60 KB
<class 'code | 2974 | 419.56 KB
<class '_io.BufferedWriter | 2 | 256.34 KB
<class 'set | 420 | 159.88 KB
<class '_io.BufferedReader | 1 | 128.17 KB
<class 'wrapper_descriptor | 1130 | 88.28 KB
<class 'tuple | 1304 | 86.57 KB
<class 'weakref | 1013 | 79.14 KB
<class 'builtin_function_or_method | 958 | 67.36 KB
<class 'method_descriptor | 865 | 60.82 KB
<class 'abc.ABCMeta | 62 | 59.96 KB
<class 'list | 446 | 58.52 KB
<class 'int | 1425 | 43.20 KB
有关muppy的更多信息，请参阅muppy文档。
无泄漏的泄漏¶
有时，你可能会注意到你的Scrapy进程的内存使用量只会增加，而不会减少。不幸的是，即使Scrapy或你的项目没有内存泄漏，这种情况也可能发生。这是由于Python的一个（不太为人所知的）问题，在某些情况下，它可能不会将释放的内存返回给操作系统。有关此问题的更多信息，请参阅：
Evan Jones提出的改进，在这篇论文中有详细说明，这些改进在Python 2.5中被合并，但这只是减少了问题，并没有完全解决它。引用论文中的话：
不幸的是，这个补丁只能在不再分配任何对象的情况下释放一个内存区域。这意味着碎片化是一个大问题。一个应用程序可能有许多兆字节的可用内存，分散在所有内存区域中，但它将无法释放其中的任何一部分。这是所有内存分配器都会遇到的问题。解决这个问题的唯一方法是转向一个压缩垃圾收集器，它能够移动内存中的对象。这将需要对Python解释器进行重大更改。
为了保持内存消耗合理，您可以将任务分成几个较小的任务，或者启用持久任务队列，并不时停止/启动爬虫。