调试内存泄漏

在 Scrapy 中，requests（请求）、responses（响应）和 items（项目）等对象具有有限的生命周期：它们被创建、使用一段时间后最终被销毁。

在所有这些对象中，Request（请求）可能是生命周期最长的，因为它一直停留在调度器队列中等待处理。更多信息请参阅架构概览。

由于这些 Scrapy 对象具有（相当长）的生命周期，总是存在在内存中累积它们而未能正确释放的风险，从而导致所谓的“内存泄漏”。

为了帮助调试内存泄漏，Scrapy 提供了一个内置的对象引用跟踪机制，称为trackref；您还可以使用第三方库muppy进行更高级的内存调试（更多信息请参阅下文）。这两种机制都必须从Telnet 控制台使用。

常见的内存泄漏原因

Scrapy 开发者在 Requests（请求）中传递引用的对象（例如，使用cb_kwargs或meta属性或请求回调函数）的情况非常常见（有时是偶然，有时是故意的），这实际上将这些引用对象的生命周期绑定到了 Request 的生命周期。这是 Scrapy 项目中最常见的内存泄漏原因，也是新手很难调试的问题。

在大型项目中，爬虫通常由不同的人编写，其中一些爬虫可能存在“泄漏”，从而在它们并发运行时影响其他（编写良好）的爬虫，进而影响整个爬取过程。

泄漏也可能来自您编写的自定义中间件、管道或扩展，如果您没有正确释放（先前分配的）资源。例如，在spider_opened时分配资源但未在spider_closed时释放，如果您以每个进程运行多个爬虫的方式，可能会导致问题。

Requests 过多？

默认情况下，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 跟踪的对象都来自这些类（及其所有子类）

一个实际例子

让我们来看一个假设的内存泄漏的具体例子。假设我们有一个爬虫，其中有一行类似这样的代码

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

活动响应如此之多（而且它们如此之旧）这一事实绝对值得怀疑，因为与 Requests（请求）相比，响应的生命周期应该相对较短。响应的数量与请求的数量相似，所以它们看起来以某种方式被绑定在一起。我们现在可以去检查爬虫代码，找出产生泄漏的“罪魁祸首”那一行（在请求内部传递响应引用）。

有时关于活动对象的额外信息可能会有帮助。让我们检查最旧的响应

>>> 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 模块中可用的函数。

class scrapy.utils.trackref.object_ref[source]: 如果您想使用 trackref 模块跟踪活动实例，请继承此类。

scrapy.utils.trackref.print_live_refs(class_name, ignore=NoneType)[source]

打印活动引用的报告，按类名分组。

参数：: ignore (type 或 tuple) – 如果给定，将忽略来自指定类（或类元组）的所有对象。

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 解释器进行重大更改。

为了保持内存消耗在合理范围内，您可以将任务分成几个较小的任务，或者启用持久化任务队列并时不时地停止/启动爬虫。