接收到 RST 包后的处理逻辑位于 tcp_input.c at v4.15:
1 | /* When we get a reset we do this. */ |
接收到 RST 包后的处理逻辑位于 tcp_input.c at v4.15:
1 | /* When we get a reset we do this. */ |
今天看了个小问题,即日志中出现了 OOM,但是发现没有对应的堆转储生成,导致 Agent 未监控到 OOM,仔细查看相关日志,发现是 Spring 的请求处理逻辑中对 Throwable 进行了 catch 然后包装了相关异常,该组应用使用的 Spring 版本为 5.3.20,相关源码位于 DispatcherServlet.java at v5.3.20:
1 | /** |
本来是排查 JDK-8265836 导致的 CPU 使用率不准确的问题,无意发现该修复方案存在一点小问题,顺手提交了个 PR 进行修复。
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
最近查了个与 CLOSE_WAIT 状态有关的问题,在此简要记录。首先背景是在业务高峰期时由于同事误操作下掉了某组应用一半以上的后端服务器,导致流量全部打在剩余的后端服务器上,由于剩余的后端服务器不足以支撑所有的流量,接口响应时间开始增大,Tomcat 线程池中的活跃线程数迅速增加至 200,接着就是负载均衡侧对后端服务器的健康检查不能成功,检活失败次数达到设置的检活阈值后即自动将不健康的后端服务器进行了摘除,随着后端服务器的摘除,剩余的后端服务器更加不能支撑线上流量,最后导致该组应用的所有后端服务器被摘除。收到告警后同事立即增加了线上后端服务器实例个数,但是服务并没有恢复,不仅之前被负载均衡摘除的后端服务器没有及时恢复,新加入的后端服务器在短暂的服务后也被负载均衡判定为不健康随即被摘除。整个服务面临的情况就是在业务高峰期无法进行冷启动的问题,随即同事在应用层对相关核心接口进行了限流以尝试逐步恢复服务,但是接口限流后服务也没有立即恢复,而是在四十分钟后,服务逐步恢复。由于事故发生时我正在外面做核酸检测,所以并没参与处理此次线上事故。在该次事故后,我从事故发生时采集到的相关监控数据来尝试还原事故现场并分析服务不能快速恢复的原因。
Fix a race condition caused by other threads calling mapper methods while mappedStatements are being constructed by tianshuang · Pull Request #2709 · mybatis/mybatis-3 · GitHub
GitHub - tianshuang/mybatis-race-condition
HashMap resize() while single thread writing and multiple threads reading - Stack Overflow