当迭代地解析XML文件时,严重的内存泄漏
上下文
当迭代一组Rdata文件(每个包含一个HTML代码的字符向量),通过加载,分析(通过XML功能),然后再次从内存中删除,我经历了显着增加 它似乎就像 通过free()释放对象, 没有任何效果,所以内存消耗累积到没有更多的内存剩余. 编辑2012-02-13 23:30:00 由于作者和包装XML的维护者Duncan Temple Lang共享了宝贵的见解(再次:非常感谢!),这个问题似乎与外部指针被释放的方式和垃圾收集处理方式密切相关XML包. Duncan发布了一个错误修复的软件包版本(3.92-0),该版本整合了解析XML和HTML的某些方面,并提供了一个改进的垃圾回收,在此不再需要通过free()明确地释放包含外部指针的对象.您可以在Duncan的Omegahat website找到源代码和Windows二进制文件. 编辑2012-02-13 23:34:00 不幸的是,新的软件包版本似乎并没有解决我遇到的问题.我遵循一些建议,并简化了一些例子,使其更容易掌握,并找到似乎出错的相关函数(检查函数./lib/exampleRun.R和.lib / scrape.R). 编辑2012-02-14 15:00:00 Duncan建议试图强制通过.Call(“RS_XML_forceFreeDoc”,html)显式释放已解析的文档.我在示例中添加了一个逻辑开关(在脚本./scripts/memory.R中为do.forcefree),如果设置为TRUE,那么将执行此操作.不幸的是,这使我的R控制台崩溃.如果有人可以在他们的机器上验证这件事情会很棒!实际上,当使用最新版本的XML时,文档应该被自动释放(见上文).事实上它似乎不是一个bug(根据邓肯). 编辑2012-02-14 23:12:00 邓肯将另一个版本的XML(3.92-1)推送到他的Omegahat网站Omegahat website.这应该解决这个问题.然而,我似乎没有运气与我的例子,因为我仍然遇到相同的内存泄漏. EDIT 2012-02-17 20:39:00>解! 是!邓肯发现并修复了错误!在Windows的唯一脚本中有一点错字,它解释了为什么在Linux,Mac OS等中没有显示错误.请查看最新版本3.92-2.!内存消耗现在与迭代解析和处理XML文件时一样恒定! 特别感谢邓肯寺郎,感谢所有回应这个问题的人! >>>原始问题的法律部分<<< 示例说明(编辑2012-02-14 15:00:00) 关于内存控制的事情 >确保在每次迭代结束时通过rm()重新删除加载的对象. 编辑2012-02-13 23:42:00: 系统信息 > Windows XP 32位,4 GB RAM 截至2012-02-09 01:00:00的初步调查结果 >在几台机器上运行Webscraping方案(参见上面的“系统信息”一节)总是在大约180 – 350次迭代之后破坏了R进程的内存消耗(取决于操作系统和RAM). 问题 >任何想法是什么导致内存增加? 截止2012-02-013 23:44:00 在几台机器上运行示例(./scripts/memory.R)(参见上面的“系统信息”部分),在大约180 – 350次迭代(取决于操作系统和RAM)之后,仍然会破坏R进程的内存消耗. 内存消耗仍然明显增加,即使在查看数据时可能看起来不是那么大,因此我的R进程总是在某种程度上死亡. 下面我已经发布了几个时间序列,这是通过在具有2 GB RAM的WinXP 32位盒上运行我的例子所得到的: TS_1(XML 3.9-4,2012-02-09) 29.07 TS_2(XML 3.9-4,2012-02-09) 28.54 与TS_2关联的错误消息 [...] Scraping html page 30 of ~/data/rdata/132.rdata Scraping html page 31 of ~/data/rdata/132.rdata error : Memory allocation failed : growing buffer error : Memory allocation failed : growing buffer I/O error : write error Scraping html page 32 of ~/data/rdata/132.rdata Fehler in htmlTreeParse(file = obj[x.html],useInternalNodes = TRUE,addFinalizer = TRUE): error in creating parser for (null) > Synch18832464393836 TS_3(XML 3.92-0,2012-02-13) 20.1 与TS_3相关的错误信息 [...] ---------- status: 31.33 % ---------- Scraping html page 1 of 50 Scraping html page 2 of 50 [...] Scraping html page 36 of 50 Scraping html page 37 of 50 Fehler: 1: Memory allocation failed : growing buffer 2: Memory allocation failed : growing buffer 编辑2012-02-17:请帮我验证计数器值 如果你可以运行下面的代码,你会给我很大的帮助. >下载一个Rdata file并保存为seed.Rdata. 码: setwd("set/path/to/your/wd") install.packages("XML",repos="http://www.omegahat.org/R") library(XML) source("scrape.R") load("seed.rdata") html <- htmlParse(obj[1],asText = TRUE) counter.1 <- .Call("R_getXMLRefCount",html) print(counter.1) z <- scrape(html) gc() gc() counter.2 <- .Call("R_getXMLRefCount",html) print(counter.2) rm(html) gc() gc() 我对counter.1和counter.2的值非常感兴趣,在两个调用中应该是1.事实上,在邓肯已经测试过的所有机器上.然而,事实证明,counter.2在我所有的机器上都有值259(见上面的细节),这正是导致我的问题的原因.
从XML包的网页上看,作者Duncan Temple Lang似乎已经广泛地描述了某些内存管理问题.见本页:
“Memory Management in the XML Package”.
老实说,我没有精通你的代码和包的细节,但是我想你可以在该页面找到答案,特别是在“Problems”节,或者直接与邓肯寺交流郎. 更新1.可能有用的一个想法是使用多核和foreach包(即listResults = foreach(ix = 1:N)%dopar%{your processing; return(listElement)})我认为,对于Windows,您将需要doSMP或者可能是doRedis;在Linux下,我使用的是doMC,在任何情况下,通过并行化加载,您将获得更快的吞吐量,我认为您可能从内存使用中获益的原因在于,可能导致不同的内存清理,因为每个产生的进程在完成时都会被杀死,这不能保证工作,但它可以解决内存和速度问题. 请注意,doSMP有其自己的特点(即,您可能还会遇到一些内存问题).还有另外一些关于SO的问题提到了一些问题,但我仍然会给它一个镜头. (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |