耗内存应用优化实际案例

Author：放翁（文初）

Email:[email protected]

mblog: http://t.sina.com.cn/fangweng

         这里分享的是一个分布式分析系统的Master内存消耗状况的优化，有些比较特定的优化未必适用于其他系统，但是从这一系列优化过程中，应该能带给其他系统在做设计时提前考虑一点优化点。

         下面先描述一下背景，看了背景可以对后续的优化点可以比较清楚一些，注意，部分设计仅适用于大量计算中，会牺牲可维护性来换取性能提升。最后一点优化应该是比较有通用性意义的。

 

背景：

         开放平台每天产生大量的调用日志，希望能够从海量日志中即时的去分析业务指标和系统运行状况。当前实现的是类似MapReduce的设计，不过Master与Slave之间是松耦合的关系，比传统的MapReduce更利于扩展和即时分析（当然和Hadoop的目标是不一致的，规模量及作用也不同，主要用于统计规则易变，需要即时分析，数据量在T以内），同时内嵌了统计规则引擎，使得统计逻辑只需要通过配置即可实现分析定义。具体的部署图和流程图如下：

 

流程如下：

Master与Slave之间没有注册和管理的关系，Slave连接到Master请求任务，从任务中获取数据来源，分析规则配置，获取数据块大小的信息，然后将数据块拉下来分析，最后返回结果给Master。至此，Master与Slave的交互完成。

Master自身主要负责：

1.              任务列表创建和重置（根据配置信息创建任务列表，由于是增量对应用服务器分析，则定期将任务全部重置，可以让Slave增量的对应用服务器去拖取数据分析）。

2.              重置一些分配出去但是较久都没有执行的任务，防止Slave任务执行失败没有反馈而出现死等的现象。

3.              合并Slave传递过来已完成的任务结果集到主干结果集上。

4.              将主干结果集定时输出提供给第三方使用（告警，图形化等），导出中间结果，提供给Master异常重启后回复现场使用。

 

问题：

         由于报表配置增多，单报表的结果数据量大，Master合并多个结果集内存吃紧，不断的GC，最后导致恶性循环。因此优化原先认为任务不重的Master迫在眉睫。

 

优化过程：

1．  合并过程中，主干结果和Slave结果都比较大，在操作后是否可以通过主动clear和set null来更快的清理释放资源。（基本没有效果，GC已经做了很多优化）