 |
me1onsodaSep 13, 2024
1
你这样算时间是极不靠谱的，编译器会对指令重排序
|
 |
31415926535xSep 13, 2024
3
@Plumes 测试环境可重试的话，尝试用 arthas 抓一下看看是哪个方法的问题
|
 |
v2hhSep 13, 2024
4
是不是那个时间点数据库连接池占满了
|
 |
hubqinSep 13, 2024
6
会不会集群或网络里面有两个 mysql 实例，形成了负载均衡，其中一个是性能较差的
|
 |
JYiiSep 13, 2024
8
代码硬看不出问题的话，看一下时段的主机、服务、数据库的情况
|
 |
sagaxuSep 13, 2024
9
把 GC 日志也开了，full gc 也会引起类似情况。既然是每天的 16:10 分左右，那要排查下四点之后有没有计划任务，不局限于这个进程。
|
 |
trzzzzSep 13, 2024
10
如果 op 用的 druid ，可能耗时在 druid 的获取连接和归还连接那边。jstack 配合 arthas 抓一下吧
|
 |
mark2025Sep 13, 2024
11
备份进程导致高 io ？
|
 |
falsemaskSep 13, 2024
12
1.数据库用了连接池吗？
2.更新会有行锁吗？ |
 |
babyrjwSep 13, 2024
13
应该是有其他大事务把 id=220269386 这条记录锁住了。
锁住的可能有几种，update 的条件命中 id=220269386 或者 lock_status = 4 或者 lock_etime=1726041977 都会锁住这条记录，可以看一下慢查询日志 |
 |
14
@babyrjw 日志里已经出现 updates: 1 ，按照我的理解这应该已经完成提交了吧，查了数据库的 binlog ，也看到已经很快 commit 了
|
 |
16
给你个极端的原因，定期 roll 日志文件的时候 io 塞住了
|
 |
cheng6563Sep 14, 2024
17
随机卡，还一卡卡那么久，考虑是随机数生成器问题了.
-Djava.security.egd=file:/dev/urandom |
|
18
@siweipancc 附言里有今天的机器磁盘监控，看上去 16 点左右没什么异常
|
 |
nealHuangSep 19, 2024
20
mark 跟踪一下，有思路麻烦各个吴彦祖踢我一下
|
 |
baoshijiagongSep 23, 2024
21
日志的内容里面耗时这个是当前时间减去 startTime ，startTime 在哪定义的，从截图看并不知道，那么截图里高亮的两个“当前耗时”和“耗时”没有可比性，先忽略。
17.039 的是 updateTagsModuleLibsById 的日志 18.080 的是 updateModuleLibById 的日志 不是两条相邻代码的日志。 updateModuleLibById 方法没有产生 sql 日志。 没有任何不合理之处。 接口延迟，只是 updateModuleLibById 处理时间长了，要查一下这个方法为什么在特定时间，比如刚过 16 点的时候，会有延迟。 |
1
Select Language