生产问题记录
文章平均质量分 92
个人生产中遇到的问题记录
lcn29
lcn29.github.io
展开
-
【生产问题记录】一次 CPU 占用率过高的问题排查 (不断创建线程和线程上下文频繁切换)
至此, 整个 CPU 占用率高的排查过程就结束了, 后面再对整个过程做个总结通过比较线程栈的信息, 定位到了 @Async 注解的实现中, 通过不断创建线程执行任务的, 这个行为会导致 CPU 消耗资源在重量级对象 Thread 的创建和消毁中第二次通过观察线程栈信息, 定位到大量的线程阻塞在日志输出处, 执行的任务也是在输出日志, 猜测是频繁的日志打印, 导致线程上下文切换, 通过减少日志打印进行验证结论。原创 2023-12-10 19:12:20 · 1050 阅读 · 0 评论 -
【生产问题记录】一次简单的 Http 请求异常处理 (请求的 url 太长, Nginx 直接返回 400, 导致请求服务异常)
服务 A 的请求先经过 Nginx, 再由 Nginx 转发到 B。而异常的用户的请求到了 Nginx, Nginx 直接返回了 400, 从而导致用户请求异常。通过查询资料, Nginx 报 400 的场景如下request_uri 过长超过 nginx 配置大小cookie 或者 header 过大超过 nginx 配置大小空 HOST 头content_length 和 body 长度不一致我遇到的情况就是第一种。原创 2023-11-23 23:57:55 · 1445 阅读 · 0 评论 -
【生产问题记录】一次 MQ 堆积的解决 (并发地从数据库中查询出大量数据导致数据库繁忙最终宕机)
查看堆内存设置为 2G (-Xmx2G, 小堆多实例的配置), 先尝试将堆内存设置为 4G (-Xmx4G), 解决上面的异常, 让应用能够继续消费。同样通过 jstack 查看, 消费线程都是 Runnable 状态, 默认是解决了, 等消息消费完就行了, 回到旧版本, 定位原因。这种 MQ 堆积的情况, 个人习惯都会先确定一下对应的消费线程的状态, 确定是消费慢, 还是消费阻塞等原因。所有的消费线程都是进入 WAITING 状态, 失去了消费能力, 连续抽查了几台生产实例, 都是相同的情况。原创 2023-11-07 16:34:24 · 277 阅读 · 0 评论 -
【生产问题记录】一次接口大量异常的排查 (大对象强引用, 无法回收, 导致一直在 GC)
记录一次因大对象强引用, 无法回收, 导致应用一直在 GC 的排查过程。原创 2023-10-22 14:17:19 · 113 阅读 · 0 评论