用户画像系列——在线服务调优实践
前面文章讲到画像的应用的几个方面，其中画像的在线服务应用主要是在推荐场景、策略引擎场景，这两部分场景都是面向线上的c端服务。
推荐场景：根据不同的用户推荐不同的内容，做到个性化推荐，需要读取画像的一些偏好数据，推荐感兴趣的内容。
策略引擎：根据用户的属性进入到不同的页面或者给出不同的策略，比如：普通用户访问不了淘宝的奢侈品入口，北京的活动只能北京用户参加。
所以能看到画像的在线服务的业务要求，流量大、对于耗时敏感（上万或者几十万的QPS、要求在毫秒内返回结果）。
目前业界对于这种c端大流量的服务基本上是采用Redis对数据进行存储，提供对外访问。
下面是画像服务在实际线上遇到的一些问题以及问题定位和处理思路：
(1)遇到的问题——流量高峰期耗时波动有毛刺、full gc 过于频繁
流量高峰期，经常出现耗时波动，观察gc情况，发现GC过于频繁(2天左右一次full gc)
机器配置:4c 8g
jvm参数配置：-Xms6g -Xmx6g -XX:NewRatio=2 -XX:+UseParallelGC -XX:ParallelGCThreads=4 -XX:+PrintGC -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:GCLogFileSize=50M -XX:NumberOfGCLogFiles=10 -XX:+UseGCLogFileRotation -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/online-server/logs -Xloggc:/data/online-server/logs/gc.log
单台容器 qps高峰在 600-800
(2)优化方案一
机器配置:8c 16g
jvm参数:-Xms14g -Xmx14g -XX:NewRatio=2 -XX:+UseParallelGC -XX:ParallelGCThreads=4 -XX:+PrintGC -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:GCLogFileSize=50M -XX:NumberOfGCLogFiles=10 -XX:+UseGCLogFileRotation -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/online-server/logs -Xloggc:/data/online-server/logs/gc.log
Full gc:4天一次
但是Survivor 区非常小：只有13M 原因参考 https://zhuanlan.zhihu.com/p/148604647
(3)优化方案二
机器配置：8c 16g
jvm参数：-Xms14g -Xmx14g -XX:NewRatio=2 -XX:+UseConcMarkSweepGC -XX:+PrintGC -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:GCLogFileSize=50M -XX:NumberOfGCLogFiles=10 -XX:+UseGCLogFileRotation -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/online-server/logs -Xloggc:/data/online-server/logs/gc.log
Survivor ：478M
(4)优化方案三
机器配置：8c 16g
jvm：-Xms14g -Xmx14g -XX:NewRatio=1 -XX:+UseConcMarkSweepGC -XX:ParallelGCThreads=4 -XX:+PrintGC -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:GCLogFileSize=50M -XX:NumberOfGCLogFiles=10 -XX:+UseGCLogFileRotation -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/online-server/logs -Xloggc:/data/online-server/logs/gc.log
提升新生代大小，主要是查询服务的数据中含有很大的对象数据，短暂使用即可回收，不会常驻。
最终优化之后，full gc 维持在1周一次，但是仍然有接口耗时毛刺。
第二步：利用Arthas接口优化实践
核心逻辑主要是从Redis中里面读数据+同时根据权限解析响应有权限的标签返回，下面是利用Arthas对接口的好是分析和较高耗时的时候传递的参数的分析
最终查看这部分耗时较高的id主要是value值数据量非常庞大，导致从Redis读取+解析耗时非常严重甚至达到秒级，虽然最终返回的结果数据不算太大，但是读取和解析耗时非常严重
从调优来看，虽然能通过增大机器资源4c 8g——8c 16g，同时通过调整jvm参数让full gc 能够达到一周一次，但是对于接口波动还是存在问题，主要原因就是某些id对应的value值较大，所以读取和解析耗时严重，因此最终方案应该考虑去对value进行拆分存储，避免一次性取出来过大的数据，将常用数据和非常用数据进行拆分。
本文分析通过调整jvm参数以及利用Arthas进行分析接口耗时情况来进行定位在线服务问题。
博客地址：https://zgzf.online/
本文由博客一文多发平台 OpenWrite 发布！
