一个有点挑战的问题,brew下连续内存空间,请高手关注。

halake 2010-02-26 11:28:20
现在的问题是:
1。用brew的 GETRAMFREE()可以获得 total剩余空间和 最大的连续可分配空间信息,发现为11M和11M。
2.连续调用一个第三方应用后关闭后,为11M和3M。
3.现在启用一个本地应用,发现起不来,原因是需要大于3M的连续内存。

如上问题,请高手给个方案。brew本身没有对剩余内存进行整理的。
...全文
2831 15 打赏 收藏 转发到动态 举报
写回复
15 条回复
切换为时间正序
请发表友善的回复…
发表回复
qq274840476 2012-03-30
  • 打赏
  • 举报
回复
之前我们公司对于第三方模块内存泄漏导致 最大块内存一直减少的问题也很困扰。

最大快内存的减少最主要的原因就是内存泄漏(也可能是第三方调用某些系统组件没被释放)。

如果在无法解决内存泄漏的最好是对内存进行管理:

如刚开机就分配个几M的内存,如果需要分配的内存为几K的时候 就从这段内存中提取
这样也只能保证,使用长久点而已,无法根治
qpbn10 2011-10-02
  • 打赏
  • 举报
回复
我也挺有兴趣知道结果是怎样?
crmchan 2011-04-14
  • 打赏
  • 举报
回复
不知道楼主最后分析
的结果是什么?
悠然红茶 2010-02-28
  • 打赏
  • 举报
回复
BREW内部的内存管理机制会把所有空闲可用的节点记在链表中,每当申请内存时,会寻找一个与所申请大小最接近的节点然后摘下这个节点。当然,如果节点大小和所申请大小不完全相符的话,会自动对这个节点进行一次切割。如果找不到够大的节点,就尝试做一次合并。

除了空闲列表外,堆中所有节点还被实现成一条单向链表,做合并的时候便于遍历。当发现相邻的两个节点描述的RAM都是可用的时,就可以合并成一个节点了。所以是真正合出了一个新的大一点的节点。当然如果合并后还是找不到足够大的内存,那么就只能返回NULL了。
halake 2010-02-27
  • 打赏
  • 举报
回复
引用 8 楼 codefly 的回复:
不知道你是否具有这个第三方应用的代码,可以先分析看看里面有没有内存泄漏。会不会像sxcnfly说的那样破坏了node,也不好说,不过一般情况下,破坏node后,机器很快就崩溃了,也不大像你描述的样子。我只是怀疑:
1)第三方应用可能通过某种方式进入了系统上下文,并且申请了内存。这种内存不会在app退出后被BREW立即回收,于是就产生泄漏了。
2)扩展来讲,也有可能第三方应用本身没什么问题,只是向其他applet发了什么事件,而其他applet可能在处理该事件时申请了内存,又没有释放。

hi,codefly
问题1:关于Heap内存回收的,如果使用MALLOC()和IHEAP_Malloc(),Brew机制里,IHEAP_Malloc会对申请不到的内存进行合并,但不是搬移,是回收后连接到可用的内存链表里的结尾,还是整合在一起了?也就是说,其实还是不会有连续足够的内存空间?

问题2:第三方应用计入系统上下文的这个。目前来看,造成了内存碎片是可以肯定,泄漏的内存至于是否被回收,我可以先做个试验,只用Bing search的情况下,看看能不能复现这情况。打印对大连续内存块看看。

问题3:你刚才回复的第二点,很有可能,现在就是需要第三应用bing search调用 navigator后才会出现这种问题。产生了内存折半的分割。这个需要再仔细看看log。稍后通知结果。
halake 2010-02-27
  • 打赏
  • 举报
回复
引用 4 楼 sxcnfly 的回复:
引用 1 楼 codefly 的回复:调用的第三方应用是否有内存泄漏,导致一直占着几个字节,于是每次启动都从剩余部分的新区域申请内存。如此往返几次,本地应用就找不到大于3M的连续内存了。 heap管理模块会在申请不到内存时,做一次内存合并,然后再看是否能找到足够大小的块。如果找不到就返回NULL。不过这种合并动作不会进行内存内容搬移,只是合并而已。
可能是某些内存Node被破坏了,否则即使应用有泄漏,brew在unload应用时都会把此应用使用的内存块都回收的。


如果按sxcnfly的中假设,Node被破坏,本地大内存使用的应用有可能都会出现问题。但是现在的征兆是,别的应用都正常,唯独这个3M连续空间的Wap浏览器应用调用不起来。还有没有别的可能性?
sxcnfly 2010-02-26
  • 打赏
  • 举报
回复
引用 1 楼 codefly 的回复:
调用的第三方应用是否有内存泄漏,导致一直占着几个字节,于是每次启动都从剩余部分的新区域申请内存。如此往返几次,本地应用就找不到大于3M的连续内存了。
heap管理模块会在申请不到内存时,做一次内存合并,然后再看是否能找到足够大小的块。如果找不到就返回NULL。不过这种合并动作不会进行内存内容搬移,只是合并而已。

可能是某些内存Node被破坏了,否则即使应用有泄漏,brew在unload应用时都会把此应用使用的内存块都回收的。
beyondma 2010-02-26
  • 打赏
  • 举报
回复
这个贴子要关注一下,感觉很有加精的潜力!
malu_1982 2010-02-26
  • 打赏
  • 举报
回复
同意楼上同学的观点。
三方应用应该有泄漏。
悠然红茶 2010-02-26
  • 打赏
  • 举报
回复
调用的第三方应用是否有内存泄漏,导致一直占着几个字节,于是每次启动都从剩余部分的新区域申请内存。如此往返几次,本地应用就找不到大于3M的连续内存了。
heap管理模块会在申请不到内存时,做一次内存合并,然后再看是否能找到足够大小的块。如果找不到就返回NULL。不过这种合并动作不会进行内存内容搬移,只是合并而已。
悠然红茶 2010-02-26
  • 打赏
  • 举报
回复
不知道你是否具有这个第三方应用的代码,可以先分析看看里面有没有内存泄漏。会不会像sxcnfly说的那样破坏了node,也不好说,不过一般情况下,破坏node后,机器很快就崩溃了,也不大像你描述的样子。我只是怀疑:
1)第三方应用可能通过某种方式进入了系统上下文,并且申请了内存。这种内存不会在app退出后被BREW立即回收,于是就产生泄漏了。
2)扩展来讲,也有可能第三方应用本身没什么问题,只是向其他applet发了什么事件,而其他applet可能在处理该事件时申请了内存,又没有释放。
halake 2010-02-26
  • 打赏
  • 举报
回复
加了log,打印了内存信息,发现:
1.第一次启动第三方应用(为动态BREW应用的Bing search和Navigator)调用后,剩余内存为:11M左右,最大连续内存为:6M。
2.第二次调用后,剩余内存为:11M左右,最大连续内存为:3M。
2.第二次调用后,剩余内存为:11M左右,最大连续内存为:1.5M。无法调用本地应用。

初步看来,这个bing search东东每次对内存进行切割,还是近一半一半的切割。

目前可以找到一个方案:
对本地应用进行静态内存分配,实现方式为分配一个静态数组给本地应用,这个是写入代码区的静态常驻内存。
缺点:浪费了近3M的手机内存,别的应用无法动态分配获取。

那位有更好的方案。
halake 2010-02-26
  • 打赏
  • 举报
回复
引用 1 楼 codefly 的回复:
调用的第三方应用是否有内存泄漏,导致一直占着几个字节,于是每次启动都从剩余部分的新区域申请内存。如此往返几次,本地应用就找不到大于3M的连续内存了。
heap管理模块会在申请不到内存时,做一次内存合并,然后再看是否能找到足够大小的块。如果找不到就返回NULL。不过这种合并动作不会进行内存内容搬移,只是合并而已。


大侠,说heap会对内存进行管理合并,能说的具体点不?我们能不能采取什么方式认为干预?
halake 2010-02-26
  • 打赏
  • 举报
回复
[Quote=引用楼主 halake 的回复:]
楼上这位高手,说heap会对内存进行管理合并,能说的具体点不?

现在的问题是:
1。用brew的 GETRAMFREE()可以获得 total剩余空间和 最大的连续可分配空间信息,发现为11M和11M。
2.连续调用一个第三方应用后关闭后,为11M和3M。
3.现在启用一个本地应用,发现起不来,原因是需要大于3M的连续内存。

如上问题,请高手给个方案。brew本身没有对剩余内存进行整理的。
相关推荐
OneAPM智能运维平台解决方案 ——用人工智能点亮您的IT数据 OneAPM智能运维平台解决方案ppt课件全文共46页,当前为第1页。 2 议题 1 从人工到人工智能 3 迈出AIOps的第一步 2 用人工智能点亮您的IT数据 . OneAPM智能运维平台解决方案ppt课件全文共46页,当前为第2页。 3 议题 1 从人工到人工智能 3 迈出AIOps的第一步 2 用人工智能点亮您的IT数据 . OneAPM智能运维平台解决方案ppt课件全文共46页,当前为第3页。 4 当前运维和业务团队面临的困境 不是没有数据,而是数据太多 不是不想分析,而是无从下手 . OneAPM智能运维平台解决方案ppt课件全文共46页,当前为第4页。 5 从人工到人工智能 挖掘海量数据的业务价值 统一大数据分布式处理技术 智能算法与机器学习 业务系统将要发生什么? 主动响应的预防预测性管理 降低系统低效对业务的影响 多种分散独立监控工具 专业化专家型人才 业务系统已经发生了什么? 被动响应的故障恢复性管理 人工运维 AIOps . OneAPM智能运维平台解决方案ppt课件全文共46页,当前为第5页。 6 什么是AIOps AIOps,即基于人工智能的IT运维(Artificial Intelligence for IT Operations) ,是由Gartner定义的IT运维管理新类别。 AIOps将服务管理、性能监测、自动化结合在一起,以实现持续洞察和改进的目标,并由大数据和机器学习技术进行支撑。 机器学习 大数据 平台 AIOps 商业价值 监测 (观察) 服务管理 (交互) 自动化 (行动) 持 续 察 洞 持 续 洞 察 持 续 洞 察 From Gartner's Report . OneAPM智能运维平台解决方案ppt课件全文共46页,当前为第6页。 7 AIOps的四个核心能力 AIOps 对海量数据进行存储 通过智能算法在数据提取时和存储后进行分析 从不同的数据源中获取数据 对海量数据进行高效访问 . OneAPM智能运维平台解决方案ppt课件全文共46页,当前为第7页。 8 AIOps的技术栈 可视化 机器学习 算法 分析 计算 大数据 数据源 事件 日志 监控 工单 任务 全量,海量,多样性,复杂性IT数据 集中统一管理,历史数据存储,实时数据存储 数据建模,模式识别,趋势识别,故障隔离 智能化选择,异常检测,异常定位,根因分析 算法自我修改演进,新算法创建 多维度,个性化,角色化,场景化展示 数据清洗,去重,过滤,关联,生成新数据 . OneAPM智能运维平台解决方案ppt课件全文共46页,当前为第8页。 9 AIOps的核心价值 故障发现 故障规避 故障止损 故障修复 异常检测 异常定位 根因分析 异常预测 . OneAPM智能运维平台解决方案ppt课件全文共46页,当前为第9页。 10 AIOps将在5-10年内成为ITOM的主流技术 From Gartner's Report . OneAPM智能运维平台解决方案ppt课件全文共46页,当前为第10页。 11 议题 1 从人工到人工智能 3 迈出AIOps的第一步 2 用人工智能点亮您的IT数据 . OneAPM智能运维平台解决方案ppt课件全文共46页,当前为第11页。 12 OneAPM智能运维平台解决方案 服务器数据 存储数据 网络数据 应用数据 用户体验数据 流量数据 日志数据 交易数据 任意IT数据 OneAPM AIOps 大数据实时多维分析 机器学习 大规模事务处理 海量数据实时接入 服务分析 深度挖掘 场景可视化 多维指标告警 数据建模 . OneAPM智能运维平台解决方案ppt课件全文共46页,当前为第12页。 13 OneAPM智能运维平台的五个能力层次 发现 接入 存储 整合 梳理 关联 智能 分析 多维 展示 从哪里来 到哪里去 IT数据 . OneAPM智能运维平台解决方案ppt课件全文共46页,当前为第13页。 14 全栈IT数据发现与接入篇 . OneAPM智能运维平台解决方案ppt课件全文共46页,当前为第14页。 15 全栈IT数据的采集范围 监控对象 采集数据 IT系统 客户端 数据库 虚拟化 中间件 SaaS 传统架构 业务层 应用软件层 基础设施层 业务系统 云架构 硬件设备 PaaS IaaS 交易 业务流程 浏览器 移动APP 应用/微服务 应用代码 数据库服务 中间件服务 网络流量包 日志 虚拟化 网络 主机 机房环境 交易量 交易金额 交易成功率 页面加载时间 浏览器类型 用户IP 页面加载错误率 CDN质量 应用响应时间 应用吞吐量 应用错误率 单个服务响应时间 单个服务吞吐量 单个服务错误率 交易错误率 交易处理时

730

社区成员

发帖
与我相关
我的任务
社区描述
为移动开发者提供丰富的解决方案、全面的技术下载。本版以游戏、多媒体、高效能等三个技术为核心,为开发者营造一个轻松、高效的学习交流平台。
社区管理员
  • Qualcomm开发
  • 霍大神
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告