4.实时推荐系统性能优化-GC排查优化

经过上节匹配优化后,通过对结果集分组,降低数据量级,使得系统接口访问量得到了显著的提升。但此时需要注意的是,我们通过业务区分降低数据量级并没有优化系统代码运行性能。由此节开始,我们来进行系统性能优化。首先是在系统运行时,通过监控发现运行时系统GC频繁。所以详细分析了下系统中存在的GC问题。

问题1:大量临时对象创建,引发频繁YoungGC

比值方法

原比值方法中,通过在方法参数map中,对input和defaultInput两个key做get后。如果不为空,则将两个标签合并至matchedMap结果中。此处我们可以看到1次比值计算,需要创建1个map、1个list。系统在运行时,1次请求,系统中每一个标签需要做一次比值计算。所以当系统中有几百标签时,系统中创建了非常多的临时变量。

由于比值方法逻辑固定,所以我们可以对入参map进行优化。当奖品配置后,预先组装好input和defaultInput两个结果,无需每次合并matchedMap结果。此处我们可以归结比值方法中两种场景,1:input为空,则结果为defaultInput, 2:input不为空,则结果为input + defaultInput。我们可以在推送奖品时预先合并结果。匹配时,直接get对应值即可。

在红框组装规则时,根据上述逻辑,预先分配input和defaultInput结果

优化比值算法

优化后比值算法,无新对象创建

问题2:大对象进入老年代,引发频繁FullGC

由于系统运行时,匹配接口均为临时变量,在YoungGC过程中应当被完全释放掉。而通过观察系统运行,发现系统中FullGC频繁。FullGC发生后,系统内存空间可以得到大量释放。

通过观察系统运行状况,发现日志中有超大的日志输出。所以推测为由于日志中大对象打印日志,导致对象被直接分配在老年代中,引发FullGC。

验证方法比较简单,直接关掉日志后,发现系统中FullGC完全消失,此后,将系统打印大日志位置进行优化,无需打印初删除日志,需要打印位置选择重点参数打印。避免整个对象丢入logger中。

《4.实时推荐系统性能优化-GC排查优化》上有1条评论

发表评论

电子邮件地址不会被公开。 必填项已用*标注