【注意】上次测试时,是上午的数据,所以当日统计数据量小
******************************************************************************************继上次优化后,再次优化************************************************************************************
【注意】这次测试时,是晚上的数据,所以当日统计数据比上次统计时数据量大1-2倍
【第一次尝试】将该模块所有能用到缓存的地方都加上本地缓存,并且尽可能少的访问数据库
【失败】导致程序各种分组计算最密集,java代码CPU1000左右,居高不下
【第二次尝试】将该模块明显耗性能的sql查询,抽取出来,进行选择性的加缓存优化
【较符合预期】mysql CPU占用保持再100-250,均值在170左右
【观察mysql CPU变化2小时】
【总结:性能优化一定是一步一步来,找到属于当前系统的最优方式,即java代码和mysql平衡】就像第一次尝试将所有能加缓存的地方都加上缓存,能少用一次查询就少用一次查询,这样将业务代码编写变得异常耗时,很费时间,最后结果还很不理想。
*************************************************************************************优化+1*********************************************************************************
【优化1】查询需要的列,只返回想要的结果;
【目的】减少mysql查询到的数据返回到内存的io操作
【优化2】前台看板数据统计由定时刷新改为5-10秒随机刷新
【目的】降低并发导致的cpu爆高的问题,(并发访问的时候,mysql CPU偶尔会到400%)
【优化3】将缓存内的数据也改为需要的数据
【目的】降低系统消耗的内存空间(由之前java代码内存5G-降为目前1G左右)
【晒图】晚间20.30
【总结】性能有提升,但不是特别明显,下一步优化则是加入增量缓存
*************************************************************************************优化+1*********************************************************************************
【尝试】查询mysql慢日志,tail -n 10000 slow.log >> slow.log_bak ,发现有A,B两个表访问比较慢
【解决】更改了其他表结构,将A表的查询替换
【结果】mysql cpu使用率 效降低了,稳定再180%左右
【再次查看慢日志】只有一个表的慢日志了
【总结】mysql慢日志明显记录了,有问题的sql,根据慢日志去优化项目,可以明显提升项目运行效率。