请选择 进入手机版 | 继续访问电脑版

笨鸟编程-零基础入门Pyhton教程

 找回密码
 立即注册

调试内存泄漏

发布者: 笨鸟自学网

在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

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


1234下一页

Archiver|手机版|笨鸟自学网 ( 粤ICP备20019910号 )

GMT+8, 2024-2-26 18:01 , Processed in 0.019508 second(s), 17 queries .

© 2001-2020

返回顶部