最近查了个与 CLOSE_WAIT 状态有关的问题,在此简要记录。首先背景是在业务高峰期时由于同事误操作下掉了某组应用一半以上的后端服务器,导致流量全部打在剩余的后端服务器上,由于剩余的后端服务器不足以支撑所有的流量,接口响应时间开始增大,Tomcat 线程池中的活跃线程数迅速增加至 200,接着就是负载均衡侧对后端服务器的健康检查不能成功,检活失败次数达到设置的检活阈值后即自动将不健康的后端服务器进行了摘除,随着后端服务器的摘除,剩余的后端服务器更加不能支撑线上流量,最后导致该组应用的所有后端服务器被摘除。收到告警后同事立即增加了线上后端服务器实例个数,但是服务并没有恢复,不仅之前被负载均衡摘除的后端服务器没有及时恢复,新加入的后端服务器在短暂的服务后也被负载均衡判定为不健康随即被摘除。整个服务面临的情况就是在业务高峰期无法进行冷启动的问题,随即同事在应用层对相关核心接口进行了限流以尝试逐步恢复服务,但是接口限流后服务也没有立即恢复,而是在四十分钟后,服务逐步恢复。由于事故发生时我正在外面做核酸检测,所以并没参与处理此次线上事故。在该次事故后,我从事故发生时采集到的相关监控数据来尝试还原事故现场并分析服务不能快速恢复的原因。
MyBatis #2709
Reference
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
java.lang.NoSuchFieldError: Companion
今天查了个与 OkHttp Maven 依赖相关的问题,本文做简单记录。起因是我们遇到一个 OkHttp 3.14.2 中存在的 bug,且此 bug 在新版本中已得到修复,于是我们将 OkHttp 升级到了最新的稳定版 4.10.0。且升级前还确认了 Upgrading to OkHttp 4 - OkHttp 中提到的不兼容的改动与该工程无关。升级后 CI 各个环境发布均正常,直到同事反馈本地工程启动报错:
1 | Caused by: java.lang.NoSuchFieldError: Companion |
RestartClassLoader
今天帮同事查了个问题,在此简单记录。起因是同事在本地开发一段时间后会触发这样的异常:
1 | 2022-09-05 18:10:28.172 ERROR - [nio-8079-exec-2] o.a.c.c.C.[.[.[.[dispatcherServlet]:175 - Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed; nested exception is java.lang.ClassCastException: me.tianshuang.dto.BizDTO cannot be cast to me.tianshuang.dto.BizDTO] with root cause |
Allocation Rate
今天排查了个内存申请率较高的问题,单个节点上 Allocation Rate 为 700MB/s,Promoted Rate 仅 300KB/s,而通过查看该组应用的历史监控,发现 Allocation Rate 之前从未超过 200MB/s。自最近一个版本发布后,Allocation Rate 翻了几倍,通过 async-profiler 对内存申请进行分析发现为业务中一段类型转换的代码导致,即 String.valueOf(long l)
方法,最后通过优化业务代码实现解决该问题。
2022-09-20
类似地,今天查了个由业务中滥用 RequestMapping
中的正则匹配导致内存申请率高的问题,此时不能直接通过请求的 URL 直接查询出关联的 HandlerMethod,而需要遍历所有的 mapping 去尝试正则匹配,导致内存申请率高,相关源码位于 AbstractHandlerMethodMapping.java at v3.2.18:
1 | /** |