笨鸟编程-零基础入门Pyhton教程 › 首页 ›Scrapy中文手册 › 查看内容

调试内存泄漏

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

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

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

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

内存泄漏的常见原因¶

Scrapy开发人员经常(有时是无意的，有时是故意的)传递请求中引用的对象(例如，使用 cb_kwargs 或 meta 属性或请求回调函数)，并且有效地将那些被引用对象的生存期限制在请求的生存期内。到目前为止，这是Scrapy项目中最常见的内存泄漏原因，对于新手来说，这也是一个很难调试的原因。

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

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

请求太多？¶

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

使用调试内存泄漏 `trackref`¶

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

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

telnet localhost 6023

>>> prefs()
Live References

ExampleSpider                       1   oldest: 15s ago
HtmlResponse                       10   oldest: 1s ago
Selector                            2   oldest: 0s ago
FormRequest                       878   oldest: 7s ago