有一套老项目 , 已经跑了几年了, 性能问题一直很好, 不存任何问题,
近期 出现数据库性能问题, 数据库负载高达50, 最低30左右, 最高 80 . 但是 %user 并不高, 20% 左右 , 说明数据库的性能还是ok 的.
只是到达数据库的请求多了, 经过对数据性能的统计分析, 发现最忙的饿时候,每秒的事务数达到里10万级别. 这个跟应用的访问量是不匹配的.
而且 ,即便数据库负载上升这么多, 到达数据库的连接增加这么多, 应用的访问量却没有明显增加.
各个mc 也运行正常.
在对日志进行分析的时候,发现了一点线索.
发现 JPA 的二级缓存 的多播协议 ,在网络层面,不通 . 有的机器之间是通的,有点机器不通.
其实 JPA 的二级缓存技术,还是相当牛 的 . 跨session 共享. 等等 . 因为这个网络协议不通,主要问题是网络丢包严重,导致分布式缓存结果,无法再集群的节点间共享,
导致了 , 页面的请求, 在本机没有cache 的情况下,无法通过共享缓存来分享cache , 只能去请求数据库了.
这就解释了, 为什么访问量没有增加, 而数据库请求 大量增加.
因为其中一台应用服务器, 的组播协议是通的, 我们把访问量最大的几个请求引到这个机器上,对数据库的根本就没有压力. 这进一步验证了,我们的猜测.
问题找到了, 那么解决问题的方法, 就很简单了.
请网络部门, 调查路由设置, 开通协议传输,更换多播地址. 问题搞定.
如果 你 的应用是基于JPA 的框架开发的, 如果业务访问量,没有增加,而 数据库访问量大增的情况下, 而又无从下手的情况,你不妨考虑 ,是不是 JPA 的分布式二级缓存的出问题了.
这个缓存出问题的最大可能性 就是 网络协议, 在网络层面 被禁止传输了.
来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/133735/viewspace-1826641/
,如需转载,请注明出处,否则将追究法律责任。