- A+
需求背景
将用户已安装APP数据从MySQL的中迁移到MongoDB的中.MySQL中存储方式比较简单,每个用户每个已安装的APP一行记录,且数据模型对应AppFromMySQL。迁移到MongoDB的中,我们想更好的利用MongoDB中的优势,所以其对应的数据模型为UserAppMongo,如果用JSON表示则如下所示:
{ "id": "201811040001", "userId": "12", "appMongoList": [{ "appName": "支付宝", "packageName": "com.alipay", "iconUrl": "http://s3.domain.com/12/12/com.alipay.jpg" }, { "appName": "淘宝", "packageName": "com.alibaba.taobao", "iconUrl": "http://s3.domain.com/12/12/com.alibaba.taobao.jpg" } ] }
问题重现
按照惯例,为了方便重现问题,将代码浓缩一下:
class AppMongo { private String appName; private String packageName; private int versionCode; private Date installTime; private String iconUrl; private String downloadUrl; private String remark; private Long size; private String developer; } // 需要保存到MongoDB中的用户已安装app信息,这样保存的好处就是MongoDB中installed_apps这张表的user_id能设置唯一键约束,查询性能相比RDBMS中数据平铺要高不少 class UserAppMongo { private String id; private Long userId; private List<AppMongo> appMongoList; } // 关系型数据库中用户已安装app class AppFromMySQL { private int id; private Long userId; private String packageName; private int versionCode; private Date installTime; private String appName; private String iconUrl; private String downloadUrl; private String remark; private Long size; private String developer; } public class FullGCSample { public static void main(String[] args) throws Exception{ for (int pageNo = 0; pageNo < 10000; pageNo++) { List<Long> userList = getUserIdByPage(pageNo); List<UserAppMongo> userAppMongoList = new ArrayList<>(userList.size()); for (Long userId:userList){ List<AppFromMySQL> appFromMySQLList = getUserInstalledAppList(userId); UserAppMongo userAppMongo = new UserAppMongo(); userAppMongo.setId(System.nanoTime()+"");//测试代码任意模拟一个伪唯一ID userAppMongo.setUserId(userId); userAppMongo.setAppMongoList(appFromMySQL2AppMongo(appFromMySQLList)); userAppMongoList.add(userAppMongo); } // save List<UserAppMongo> to mongodb save2MongoDB(userAppMongoList); } } private static void save2MongoDB(List<UserAppMongo> userAppMongoList) throws Exception { // 模拟保存一次数据到mongodb中要5ms Thread.sleep(5); } private static List<AppMongo> appFromMySQL2AppMongo(List<AppFromMySQL> list){ List<AppMongo> appMongoList = new ArrayList<>(); for (AppFromMySQL app:list){ AppMongo appMongo = new AppMongo(); //TODO bean copy appMongoList.add(appMongo); } return appMongoList; } private static List<AppFromMySQL> getUserInstalledAppList(Long useId){ List<AppFromMySQL> appFromMySQLList = new ArrayList<>(); // 假设用户手机上安装的app数量在50~200之间 int size = 50 + new Random().nextInt(150); for (int i = 0; i < size; i++) { AppFromMySQL appFromMySQL = new AppFromMySQL(i, (long)i, "com.afei.android"+i, i, new Date(), "appName"+i); appFromMySQL.setIconUrl(String.valueOf(i)); appFromMySQL.setDownloadUrl(String.valueOf(i)); appFromMySQL.setRemark(String.valueOf(i)); appFromMySQL.setSize((long)i); appFromMySQL.setDeveloper(String.valueOf(i)); appFromMySQLList.add(appFromMySQL); } return appFromMySQLList; } private static List<Long> getUserIdByPage(int pageNo){ List<Long> userList = new ArrayList<>(); // 取数据时每一页1000个用户 for (int i = 0; i < 2000; i++) { userList.add((long)i); } return userList; } }
配套的JVM参数如下(由于是迁移程序,没必要配置CMS甚至G1,默认的PS垃圾回收即可):
-Xmx400m -Xms400m -Xmn150m -verbose:gc -XX:+PrintGCDetails
后运行jstat -gcutil 57408 2s的查询查询结果如下:
S0 S1 E O M CCS YGC YGCT FGC FGCT GCT 29.81 82.88 100.00 39.35 61.05 61.52 40 16.274 7 6.756 23.030 91.43 21.01 100.00 39.26 61.05 61.52 45 17.791 8 7.327 25.118 0.00 90.53 0.00 88.47 61.05 61.52 47 18.694 9 7.327 26.021 23.00 0.00 100.00 19.10 61.05 61.52 52 19.655 10 9.227 28.882 93.29 0.00 0.00 90.25 61.05 61.52 56 21.326 11 9.227 30.553 94.21 0.00 0.00 82.39 61.05 61.52 60 22.435 12 10.253 32.688 93.23 93.23 100.00 71.09 61.05 61.52 64 23.223 12 11.027 34.250
这里有两个比较严重的问题:
- 古区涨的过快;
- FGC太频繁;
事实上第二个问题就是第一个问题引起的。
分析问题
这个案例比较特殊,虽然FGC频繁,但是每次FGC后,老都能降下去。这种情况下,我们不好通过jmap -dump得到dump文件,或者通过jmap -histo得到Java对象柱状图,因为极大可能是古区的使用率很低的时候生成的结果,这种结果没多大参考价值:
[afei@node1 ~]# jstat -gcutil 121165 100 S0 S1 E O M CCS YGC YGCT FGC FGCT GCT 0.00 0.00 40.00 15.71 58.25 51.76 287 7.891 63 2.921 10.812 96.58 0.00 18.00 34.05 58.25 51.76 289 7.937 63 2.921 10.858 96.84 0.00 0.00 70.73 58.25 51.76 291 8.001 63 2.921 10.923 0.00 0.00 0.00 27.31 58.25 51.76 291 8.033 64 2.978 11.010 0.00 99.47 0.00 45.80 58.25 51.76 293 8.077 64 2.978 11.055 0.00 96.84 0.00 83.17 58.25 51.76 295 8.144 65 2.978 11.121 96.91 0.00 0.00 21.68 58.25 51.76 296 8.157 65 3.026 11.183
那么我们有其他办法在旧区使用率很大,甚至发生FGC前生成转储文件吗当然有,这里介绍两个参数:-XX:+HeapDumpAfterFullGC和-XX:+HeapDumpBeforeFullGC。看命名就知道,这两个参数是在FGC前后生成转储文件。需要注意的是,一定是发生FGC,而不是CMS GC或者G1这种并发GC。加上-XX:+HeapDumpBeforeFullGC这个参数后,再次运行,我们看到如下这样的GC日志,即在FGC之前生成dump文件:
[GC (Allocation Failure) [PSYoungGen: 94016K->42816K(102400K)] 236438K->227942K(358400K), 0.0661795 secs] [Times: user=0.62 sys=0.88, real=0.07 secs] [GC (Allocation Failure) [PSYoungGen: 94016K->42752K(102400K)] 279142K->270606K(358400K), 0.0711319 secs] [Times: user=0.60 sys=1.01, real=0.07 secs] [Heap Dump (before full gc): Dumping heap to java_pid121598.hprof ... Heap dump file created [366886452 bytes in 1.878 secs] , 1.8782650 secs][Full GC (Ergonomics) [PSYoungGen: 42752K->0K(102400K)] [ParOldGen: 227854K->41341K(256000K)] 270606K->41341K(358400K), [Metaspace: 2828K->2828K(1056768K)], 0.1720676 secs] [Times: user=3.72 sys=0.07, real=0.17 secs]
对转储文件进行分析,结果如下,两个比较靠前的对象是UserAppMongo和AppMongo:
而通过TOP1的对象UserAppMongo的“ List Objects ” - >“ with outgoing references ”,得到如下图所示,由图可知,UserAppMongo这个对象里包含了List<AppMongo>对象(appMongoList),其本质是对象数组,每个AppMongo对象又是由APPNAME,的packageName,installTime等属性组成,所以直方图视图中排名前几位的UserAppMongo,对象[],ArrayList中,AppMongo事实上都是UserAppMongo这一个对象:
迁移程序比较简单,核心代码就那么几行,通过问题对象UserAppMongo在审查的过程中,我们很快就怀疑到了下面这段代码:
List<Long> userList = getUserIdByPage(pageNo); List<UserAppMongo> userAppMongoList = new ArrayList<>(userList.size()); for (Long userId:userList){ List<AppFromMySQL> appFromMySQLList = getUserInstalledAppList(userId); UserAppMongo userAppMongo = new UserAppMongo(); userAppMongo.setId(System.nanoTime()+""); userAppMongo.setUserId(userId); userAppMongo.setAppMongoList(appFromMySQL2AppMongo(appFromMySQLList)); userAppMongoList.add(userAppMongo); } // save List<UserAppMongo> to mongodb save2MongoDB(userAppMongoList);
这段代码的逻辑是:
- 得到一批用户ID;
- 然后遍历这些用户ID,取得每个用户已安装APP集合转换成MongoDB的需要的数据模型;
- 批量保存到的MongoDB中;
我们仔细分析一下这段代码就会发现,遍历每一页的过程中,总计有pageSize的* N * 2个对象直到保存到MongoDB中后,遍历下一页时这些对象才会得到释放,其中的pageSize是每一页的用户数量(方法getUserIdByPage中)中,n是用户平均安装APP的数量,之所以乘以2是因为有一半是MySQL的数据模型对象,另一半是MongoDB的数据模型对象。假设每一页1000个用户,用户平均安装的APP数量为100个。那么处理每一页时总计有20瓦特个对象一直常驻,且无法被GC掉。
如何解决
了解了问题的本质后,就比较好解决了,而且有很多种方法可以解决。
- 方法1-增大杨区
方法1就是增大杨区大小,准确的说是增大伊甸区大小,大到能容忍20瓦特个对象。那如果迁移程序将pageSize的改为2000,那么就需要增大伊甸区直到能容下40瓦特个对象。
- 方法2-优化代码
方法1优化办法的JVM参数还得跟pageSize的参数值耦合,有点约束。我们能否优化成无论pageSize的多大。每次内存中最大常驻对象数量是一定的呢?当然可以,请看下面这段优化后的代码:
List<Long> userList = getUserIdByPage(pageNo); List<UserAppMongo> userAppMongoList = new ArrayList<>(userList.size()); for (Long userId:userList){ List<AppFromMySQL> appFromMySQLList = getUserInstalledAppList(userId); UserAppMongo userAppMongo = new UserAppMongo(); userAppMongo.setId(System.nanoTime()+""); userAppMongo.setUserId(userId); userAppMongo.setAppMongoList(appFromMySQL2AppMongo(appFromMySQLList)); userAppMongoList.add(userAppMongo); // 核心优化代码 if (userAppMongoList.size()>=threshold){ save2MongoDB(userAppMongoList); userAppMongoList.clear(); } } // save List<UserAppMongo> to mongodb save2MongoDB(userAppMongoList);
说明:
核心优化代码的阈值的值,取一个合理的值即可。这样的话,无论getUserIdByPage()时的pageSize多大,整个堆中不可GC的驻留对象只会多几个用户id而已。
假设阈值设置为500,那么在遍历到下一页之前整个堆中不可GC的驻留对象个数为:500 * 100 * 2 = 10000,其中100是平均每个用户安装APP的数量。
这样优化以后,无论getUserIdByPage()中批量取用户时的pageSize为1000,还是5000,还是20000.JVM参数都不需要调整,且非常稳定。jstat -gcutil 56436 2s结果如下所示,运行一段时间都没有FGC,并且旧的涨幅基本可以接受:
S0 S1 E O M CCS YGC YGCT FGC FGCT GCT 35.87 0.00 54.00 3.64 61.16 61.52 52 3.894 0 0.000 3.894 0.00 50.37 48.00 3.89 61.16 61.52 67 4.392 0 0.000 4.392 12.41 0.00 46.00 4.14 61.16 61.52 80 4.990 0 0.000 4.990 1.66 14.04 100.00 4.38 61.16 61.52 89 5.636 0 0.000 5.636 0.00 27.05 24.00 4.63 61.16 61.52 103 6.146 0 0.000 6.146
- 安卓客户端下载
- 微信扫一扫
- 微信公众号
- 微信公众号扫一扫