Scrapy–调试内存泄漏

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

从所有这些对象中，请求可能是生命周期最长的请求，因为它一直在调度程序队列中等待，直到需要处理它为止。有关详细信息，请参阅 体系结构概述 .

由于这些零碎的物体有（相当长的）寿命，总有在没有正确释放它们的情况下将它们累积到内存中的风险，从而导致所谓的“内存泄漏”。

为了帮助调试内存泄漏，scrapy提供了一种内置机制，用于跟踪调用的对象引用 trackref ，您还可以使用第三方库 muppy 有关更高级的内存调试（请参阅下面的详细信息）。两种机制都必须从 Telnet Console .

内存泄漏的常见原因¶

Scrapy开发人员传递请求中引用的对象（例如，使用 cb_kwargs 或 meta 属性或请求回调函数），它有效地将这些引用对象的生存期限制为请求的生存期。到目前为止，这是导致零碎项目内存泄漏的最常见原因，对于新手来说，这是一个很难调试的原因。

在大型项目中，蜘蛛通常是由不同的人编写的，其中一些蜘蛛可能会“泄漏”，从而在其他（写得好的）蜘蛛同时运行时影响其他蜘蛛，而这反过来又会影响整个爬行过程。

如果您没有正确地释放（以前分配的）资源，那么泄漏也可能来自您编写的定制中间件、管道或扩展。例如，在上分配资源 spider_opened 但不释放它们 spider_closed 如果你跑步，可能会引起问题 multiple spiders per process .

请求太多？¶

默认情况下，scrapy将请求队列保存在内存中；它包括 Request 对象和请求属性中引用的所有对象（例如 cb_kwargs 和 meta ）虽然不一定是泄漏，但这可能会占用大量内存。有可能 persistent job queue 有助于控制内存使用。

使用调试内存泄漏 trackref¶

trackref 是Scrapy提供的一个模块，用于调试最常见的内存泄漏情况。它基本上跟踪对所有实时请求、响应、项、蜘蛛和选择器对象的引用。

您可以进入telnet控制台并使用 prefs() 函数的别名 print_live_refs() 功能：

如您所见，该报告还显示了每个类中最旧对象的“年龄”。如果每个进程运行多个spider，那么通过查看最早的请求或响应，您很可能会发现哪个spider正在泄漏。您可以使用 get_oldest() 功能（从telnet控制台）。

跟踪哪些对象？¶

被跟踪的对象 trackrefs 都来自这些类（及其所有子类）：

• scrapy.http.Request




• scrapy.http.Response




• scrapy.item.Item




• scrapy.selector.Selector




• scrapy.spiders.Spider

一个真实的例子¶

让我们来看一个假设的内存泄漏案例的具体示例。假设我们有一只蜘蛛，上面有一条和这条类似的线：

该行正在请求中传递一个响应引用，它有效地将响应生命周期与请求的生命周期联系起来，这肯定会导致内存泄漏。

让我们看看如何通过使用 trackref 工具。

当爬虫运行几分钟后，我们注意到它的内存使用量增长了很多，我们可以进入它的telnet控制台并检查实时引用：

事实上，存在如此多的实时响应（而且它们太老了），这是绝对可疑的，因为与请求相比，响应的生存期应该相对较短。响应的数量与请求的数量相似，因此看起来它们是以某种方式捆绑在一起的。我们现在可以检查蜘蛛的代码，以发现产生泄漏的讨厌的行（在请求中传递响应引用）。

有时，有关活动对象的额外信息可能会有所帮助。让我们检查最早的回答：

如果您希望遍历所有对象，而不是获取最旧的对象，则可以使用 scrapy.utils.trackref.iter_all() 功能：

蜘蛛太多了？¶

如果项目并行执行的spider太多，则 prefs() 很难阅读。因此，该函数具有 ignore 参数，该参数可用于忽略特定类（及其所有子类）。例如，这不会显示对spider的任何实时引用：

scrapy.utils.trackRef模块¶

以下是 trackref 模块。

class scrapy.utils.trackref.object_ref[源代码]¶

如果要使用跟踪活动实例，则从该类继承 trackref 模块。

scrapy.utils.trackref.print_live_refs(class_name, ignore=NoneType)[源代码]¶

打印实时引用的报告，按类名分组。

参数

ignore (type or tuple) -- 如果给定，则将忽略指定类（或类的元组）中的所有对象。

scrapy.utils.trackref.get_oldest(class_name)[源代码]¶

返回具有给定类名的最旧活动对象，或者 None 如果没有找到。使用 print_live_refs() 首先获取每个类名的所有跟踪活动对象的列表。

scrapy.utils.trackref.iter_all(class_name)[源代码]¶

返回具有给定类名的所有活动对象的迭代器，或者 None 如果没有找到。使用 print_live_refs() 首先获取每个类名的所有跟踪活动对象的列表。

用muppy调试内存泄漏¶

trackref 提供了一种非常方便的机制来跟踪内存泄漏，但它只跟踪更可能导致内存泄漏的对象。然而，在其他情况下，内存泄漏可能来自其他（或多或少模糊）对象。如果这是你的案子，而且你用 trackref ，你还有另一个资源：muppy类库。

你可以从 Pympler .

如果你使用 pip ，可以使用以下命令安装muppy:：

下面是一个使用muppy查看堆中可用的所有Python对象的示例：

有关Muppy的更多信息，请参阅 muppy documentation .

无泄漏泄漏¶

有时，您可能会注意到您的废进程的内存使用只会增加，但不会减少。不幸的是，即使Scrapy和您的项目都没有泄漏内存，也可能发生这种情况。这是由于Python的一个（不太常见）已知问题造成的，在某些情况下，该问题可能不会将释放的内存返回到操作系统。有关此问题的详细信息，请参阅：

• Python Memory Management




• Python Memory Management Part 2




• Python Memory Management Part 3

Evan Jones提出的改进建议，详情见 this paper 在python 2.5中进行了合并，但这只会减少问题，并不能完全解决问题。引用论文：

不幸的是，这个补丁只能在竞技场中不再分配对象的情况下释放竞技场。这意味着 Scrapy 化是一个大问题。一个应用程序可以有许多兆字节的空闲内存，分散在所有的区域中，但是它将无法释放其中的任何一个。这是所有内存分配器都遇到的问题。解决这个问题的唯一方法是移动到一个压缩垃圾收集器，它能够移动内存中的对象。这将需要对python解释器进行重大更改。

为了保持内存消耗合理，可以将作业拆分为几个较小的作业或启用 persistent job queue 不时停止/启动Spider。