新观点手自研OOM解决方案KOOM今日宣布开源

shanaoxuni

近日,手宣布开源KOOM,成为行业首个开源线上内存溢出(OM,以下简称OOM)问题解决方案的互联企业。据介绍,KOOM是在客户端完成内存监控后,将解析报告上传到云端,传输文件大小仅为KB级,运行时用户感知,对流量基本影响,适合大规模普及应用,目前该方案已在手全量业务中应用,OOM率降低了80%以上,效果显著。[url=http:///www.upr-e.cn/]刷赞网站[/url]的最新消息可以到我们平台网站了解一下，也可以咨询客服人员进行详细的解答！[align=center]

                               
登录/注册后可看大图

[/align
OOM是当前A开发中的常见疑难问题,尤其是线上发生的OOM问题极难定位。业界当前最知的方案LC,通过监控AF漏优化JOOM问题,多年来一直为广大保驾护航,解决了OOM治理从0到1的问题。但面对行业不断复杂的业务环境和庞大用户流量,LC仍有优化空间:受限于性能,法在线上大规模部署,仅支持线下使用;只能定位AF漏,法定位大对象、频繁分配等问题;需要人工一一分析,法对问题聚类量化……为了彻底解决OOM问题,行业尝试了多种解决方案,通常是基于LC做优化,但至今没有能完全解决监控过程中的性能问题,普遍解决方法是通过采样的办法牺牲一小部分用户的体验来定位问题。
手OOMK沿用行业的研究思路,针对LC法解决的难题进行自研改造,充分发挥LC原有优势的同时补足短板,打造了一套可以线上部署、兼顾线下、配置灵活、适用范围广泛、高度自动化,埋点、监控、解析、上报、分发、跟进、报警一站式服务的闭环监控系统,将绝大多数OOM问题拦截在灰度阶段,彻底解决了OOM问题。

KOOM框架
手KOOM核心流程包括:配置下发决策、监控内存状态、采集内存镜像、解析镜像文件(以下简称)生成报告并上传、问题聚合报警与分配跟进。
主动触发GC不卡顿
之前行业的普遍做法是通过在AD()后连续触发两次GC,并检查引用队列,判定A是否发生了漏,但频繁GC会造成用户可感知的卡顿,手为现感触发设计了全新的监控模块,通过性能损耗的内存阈值监控来触发镜像采集。将对象是否漏的判断延迟到了解析时,阈值监控只要在子线程定期获取关注的几个内存指标即可,性能损耗忽略不计。

内存监控流程图
高性能镜像DUMP
采集内存镜像传统方案会造成应用完全冻结长达几秒,期间用户完全不能操作,严重损害用户体验。手利用系统内核COW(C--,写时复制)机制,每次内存镜像前先暂停虚拟机,然后子进程来执行操作,父进程在成功后立刻恢复虚拟机运行,整个过程对于父进程来讲总耗时只有几毫秒,对用户完全没有影响。
暂停虚拟机需要调用虚拟机的:::SVM函数,谷歌从A70开始对调用系统库做了限制,手自研了-组件,通过替换和__解析绕过了这一限制。

F流程图
“不偷”用户流量的解决方案
传统方案得到的文件通常比较大,占用用户大量磁盘空间,上传大文件浪费用户流量,且不利于问题聚类分析。手采用了新的思路:采用边缘计算的思路,将内存镜像于闲时进行独立进程单线程本地分析,不过多占用系统运行时资源;分析完即删除,不占用磁盘空间;分析报告大小只有KB级别,不浪费用户流量。
分析报告生成流程总体分为个环节,第一个环节扫描镜像构建索引,建立露查找分析的基础;第二个环节查找出露的对象,根据既有的知识以及人为设定的策略,执行对象露判定;第个环节生成最终报告文件,将对象露路径、露数量、类统计、运行时信息添加至报告文件,辅助后续根据报告分析解决OOM问题。

解析镜像生成报告流程图
针对镜像回捞需求,对进行运行时裁剪,只保留分析OOM必须的数据。裁剪还有数据脱敏的好处,只保留对分析问题有用的内存中类与对象的组织结构,并不上传真的业务数据,充分保护用户隐私。
总结展望
手KOOM计划做完整的客户端内存解决方案,开发者可以通过接入KOOM,解决自己项目中的OOM问题。此次一期开源暂时只包括AJOOM解决方案,后续还将开源A线程文件描述符监控、ANOOM监控、OSOOM监控等,最终现帮助开发者解决各种场景下OOM的愿景。
手KOOMGH地址:KATKOOM

文章详情：手自研OOM解决方案KOOM今日宣布开源