性能分析之死锁和日志相关的一个实例

举报
zuozewei 发表于 2021/08/06 22:16:15 2021/08/06
【摘要】 文章目录 一、前言二、问题现象三、问题分析四、性能调优五、总结 一、前言 这个例子在做性能测试的时候出现的。 二、问题现象 团队在做性能测试,其实量并不大。只是我觉得没有什么明显的结果,于是我就自己把脚本拿来跑了一下。感觉怎么那么慢呢? 20 vusers: 40 vusers: 除了时间增加了,其他都没啥变化。系统资源也没上去。 当...

一、前言

这个例子在做性能测试的时候出现的。

二、问题现象

团队在做性能测试,其实量并不大。只是我觉得没有什么明显的结果,于是我就自己把脚本拿来跑了一下。感觉怎么那么慢呢?

20 vusers:

在这里插入图片描述

40 vusers:
在这里插入图片描述

除了时间增加了,其他都没啥变化。系统资源也没上去。
当然,还有报错。

三、问题分析

然后我就乐呵呵的找日志去了。
但是日志吧?唉,真是看不下去,那写的叫一个乱。于是我把我们的架构师给拉进来了,让他看日志去。
看着看着,一开始吧,资源都用不上去。原因是在云服务器上用了公网 iP。这种的插曲,我都不乐意截图说明了,问题低级。
修改成内网 IP 之后,流量就能上来了,但是还是不乐观。
于是开始找新问题。

在性能分析的过程中一定要记得的事情是:找到时间消耗在哪
找的手段和过程在每个系统中都会不一样,我就不再描述了。
当找到到这里的时候,基本上问题点就清晰了。

20 vusers:
在这里插入图片描述

40 vusers:
在这里插入图片描述

数据库耗时增加了。同时也看到了如下专业的错误提示:

Cause:com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: Deadlockfound when trying to get lock; try restarting transaction; SQL []; Deadlock found when trying to getlock; try restarting transaction; 

  
 
  • 1

要知道死锁是很容易看出来的,但是数据库日志中居然没报日志。
当架构师发这个给我看的时候,我就两字怼回去:不信。
我要能看到具体的死锁日志,谁锁了谁,为啥要死锁呢,多大的仇呢?
于是让架构师接着折腾,他查了代码逻辑是有问题的。

四、性能调优

在这里插入图片描述

简单来说,就是之前这个事务是直接做 update,不管有没有记录,这就导致在 mysql 中当没有记录时会产生 X-gap 锁,这时候接着做insert,但是 insert 还没有做完的时候;另一个 session 的 update、insert 又开始了,这个 session 同样没有记录,又要加 X-Gap 锁。于是死锁信息出现了。

其实这个吧,有开发经验的应该都知道这种的处理逻辑。

在这里插入图片描述

在这个例子中,当然修改不止这些。其他还有修改的是:

  1. 索引。这个索引的修改并没有引起性能的飙升,所以就不再细说了。

  2. 日志。日志是影响性能的很重要也是很常见的因素,尽量把日志合理的写出去,又小又巧的日志是最合理的。

  3. 一些参数啥的。

然后,再看下测试的结果:
在这里插入图片描述

每秒请求数可以到 400 左右了。
这时候系统资源也用起来了。

五、总结

性能分析吧,在每一个细节的事情里,几乎都是要关注的。
但是耐心还是很重要的,要不然就会像老司机一样开车不看路了。

文章来源: blog.csdn.net,作者:zuozewei,版权归原作者所有,如需转载,请联系作者。

原文链接:blog.csdn.net/zuozewei/article/details/119353722

【版权声明】本文为华为云社区用户转载文章,如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。