1
me1onsoda 6 天前
你这样算时间是极不靠谱的,编译器会对指令重排序
|
3
31415926535x 6 天前
@Plumes 测试环境可重试的话,尝试用 arthas 抓一下看看是哪个方法的问题
|
4
v2hh 6 天前
是不是那个时间点数据库连接池占满了
|
6
hubqin 6 天前
会不会集群或网络里面有两个 mysql 实例,形成了负载均衡,其中一个是性能较差的
|
8
JYii 6 天前
代码硬看不出问题的话,看一下时段的主机、服务、数据库的情况
|
9
sagaxu 6 天前
把 GC 日志也开了,full gc 也会引起类似情况。既然是每天的 16:10 分左右,那要排查下四点之后有没有计划任务,不局限于这个进程。
|
10
trzzzz 6 天前
如果 op 用的 druid ,可能耗时在 druid 的获取连接和归还连接那边。jstack 配合 arthas 抓一下吧
|
11
mark2025 6 天前
备份进程导致高 io ?
|
12
falsemask 6 天前
1.数据库用了连接池吗?
2.更新会有行锁吗? |
13
babyrjw 6 天前
应该是有其他大事务把 id=220269386 这条记录锁住了。
锁住的可能有几种,update 的条件命中 id=220269386 或者 lock_status = 4 或者 lock_etime=1726041977 都会锁住这条记录,可以看一下慢查询日志 |
16
siweipancc 6 天前 via iPhone 1
给你个极端的原因,定期 roll 日志文件的时候 io 塞住了
|
17
cheng6563 6 天前
随机卡,还一卡卡那么久,考虑是随机数生成器问题了.
-Djava.security.egd=file:/dev/urandom |
18
Plumes OP @siweipancc 附言里有今天的机器磁盘监控,看上去 16 点左右没什么异常
|
20
nealHuang 1 天前
mark 跟踪一下,有思路麻烦各个吴彦祖踢我一下
|