性能优化是个老生常谈的问题,最近在工作中遇到了类似的问题,趁机总结一下。
项目背景:java语言,微服务,使用的xxl-job,数据库为postgresql,执行对应的定时任务,会涉及到简称,A,B,C,每个表的日数据量在对应的3百到5百万数据量,A表的数据类似学生表,B,C可以理解为对应的课目的分数,
项目程序目的:算出对应学生每天考试,对应每月平均的天成绩【项目保密原因,只能这么描述了】
项目程序目前状况:卡死了,三天数据就挂掉 ,GG
然后就开始优化之路
1,查看对应日志,对应的程序中,查看对应日志打出的时间,判断每个代码块的时间,切记不能主观的认为某个地方的性能有问题而盲目的进行优化,要根据实际的程序执行情况进行分析解决
当时程序整体执行一天数据的执行时间在30分钟,A数据查询耗时5分钟,B耗时3分钟,C耗时4分钟,中间数据整合大概3分钟,最后数据整体入库时间为500万数据,耗时14分钟,从上边的时间进行推算,如果执行30天的数据要15个小时
kubectl get pods -n namespace
kubectl exec --stdin --tty ****** -- /bin/bash
cd log/
grep '关键字' log.log
根据日志计算对应的步骤耗费的时间
2,查看对应查询预计,已经是项目要求最小颗粒度的数据级别,已无法优化,使用的查询为流数据查询,整体数据放到csv后进行读流计算,
3,查看服务内存使用情况
kubectl exec --stdin --tty ****** -- /bin/bash
top
同时检查对应代码是是否使用输入流,输出流,对应的代码是否及时关闭,对应的ByteArrayOutputStream,ByteArrayInputStream内存流可以不用管,方法结束时自动会回收,即使手动处理源码中colsed方法为空
另外对应代码中使用的List在使用之后赋值null,进行内存回收
4,上边几个步骤做完之后,发现效果并不明显,开始查看对应的sql,把sql中的聚合函数 max等等,进行去除,通过程序进行处理,具体效果要明天上线才能知道哈哈,--这种方法的思路通过耗费数据的性能,转移到了程序的内存耗费上边,在进行操作时,平衡容器的内存情况进行取舍
5,备选方案,如果上述都无法解决,因为业务的情况,是每七天执行一次【执行七天的数据】,可以提前执行每天的数据,通过一个数据表或者缓存进行储存【聚合结果】,把一次执行的时长,平摊到每天
性能优化之旅是一个比较漫长的路程,祝君好运~~~~~~