最近进行压力测试,主要对jvm进行优化。因为压测时出现过OOM,主要是110个并发请求,jvn中有20万的业务对象,占1.5g。在优化前,jvm只分配了2g内存。在服务使用时,使用-XX:OnOutOfMemoryError,在出现OOM时dump出当时的内存镜像文件,可以使用jdk自带的jhat分析,也可以用MAT分析。在分析出内存大对象后,怀疑是使用自定义缓存注解,因为该业务查询gbase数据库,而gvase数据库不支持分页,所以使用自定义注解,在查询时如果返回的条数大于2000笔,则只返回2000笔数据,并将查询结果缓存到redis中,实现分页效果。在将查询结果缓存到redis时,还需要进行对象转换,导致结果集无法被回收,最终导致OOM。最后的优化方案是,在写入redis时,将集合按照100笔进行分批,每次写入一批后从集合中remove掉。再根据gc日志调整jvm大小
随手记:服务性能调优
©著作权归作者所有,转载或内容合作请联系作者
【社区内容提示】社区部分内容疑似由AI辅助生成,浏览时请结合常识与多方信息审慎甄别。
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。
【社区内容提示】社区部分内容疑似由AI辅助生成,浏览时请结合常识与多方信息审慎甄别。
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。
相关阅读更多精彩内容
- 因为总是看到很多同学在说Elasticsearch性能不够好、集群不够稳定,询问关于Elasticsearch的调...