GC Timestamp
今天查了个 GC 相关的问题,问题并不复杂,只是在比对 GC 日志中的时间与业务超时调用的时间时发现有一点偏差,原来是因为 GC 日志中的时间戳是 GC 开始前的时间戳,而我之前一直以为是 GC 完成后的时间。比如如下 GC 日志:
1 | 2022-12-16T11:10:04.939+0800: 87938160.092: [GC (Allocation Failure) 2022-12-16T11:10:04.939+0800: 87938160.092: [ParNew (promotion failed): 1850515K->1850515K(1850624K), 0.6136336 secs]2022-12-16T11:10:05.552+0800: 87938160.706: [CMS2022-12-16T11:10:06.272+0800: 87938161.426: [CMS-concurrent-mark: 1.702/2.321 secs] [Times: user=0.00 sys=0.00, real=2.32 secs] |
RST
接收到 RST 包后的处理逻辑位于 tcp_input.c at v4.15:
1 | /* When we get a reset we do this. */ |
SPR-11106
今天看了个小问题,即日志中出现了 OOM,但是发现没有对应的堆转储生成,导致 Agent 未监控到 OOM,仔细查看相关日志,发现是 Spring 的请求处理逻辑中对 Throwable 进行了 catch 然后包装了相关异常,该组应用使用的 Spring 版本为 5.3.20,相关源码位于 DispatcherServlet.java at v5.3.20:
1 | /** |
JDK-8297173
本来是排查 JDK-8265836 导致的 CPU 使用率不准确的问题,无意发现该修复方案存在一点小问题,顺手提交了个 PR 进行修复。
Reference
Java SE OperatingSystemMXBean.getSystemCpuLoad() Method Returns Incorrect Value in Containers
8265836: OperatingSystemImpl.getCpuLoad() returns incorrect CPU load inside a container by tanghaoth90 · Pull Request #3656 · openjdk/jdk · GitHub
8265836: OperatingSystemImpl.getCpuLoad() returns incorrect CPU load … · openjdk/jdk@ef368b3 · GitHub
JDK-8297173 usageTicks and totalTicks should be volatile to ensure that different threads get the latest ticks - Java Bug System