博客描述了一次在k8s环境下，Java服务因写入大量数据到Kafka后出现卡死的情况。初步检查排除了内存问题，通过监控发现CPU占用极高。进一步分析发现是由于JVM的Full GC频繁触发，导致服务假死。通过jstack、jmap等工具分析，发现是ConcurrentHashMap中的元素未被及时清理，使得GC无法有效回收，最终通过代码审查找到问题原因。
现象：往kafka写入100万条记录，最终服务只消费53万条，此时服务陷入卡死(没有退出，没有异常，不输出任何日志)
一开始认为是kafka内存或者服务pod的内存问题[root@localhost home]# docker stats | grep kafka
b00625fce123 k8s_k8skafka_kafka-0_default_94b5e113-3bfc-11e9-9038-b026282b37d0_0 1.97% 3.219GiB / 8GiB
虽然内存会一直上升，但是到最后都只是到达jvm的最大堆内存
此时认为不会只是整个pod内存的问题，可能是jvm内存导致的，之后查看cpu使用状况(服务名为service-0)[root@localhost ~]# docker stats | grep service
19acf97d231a k8s_service_service-0_default_4a431b65-3f1d-11e9-9038-b026282b37d0_0 227.89%
可以看到cpu占用一直很高
进入容器查看cpu占用高的进程[root@service-0 app]# top
查看占用cpu的线程[root@service-0 app]# top -Hp 90
可以看到93,94,95,96线程的cpu消耗很高(当时没有截图，这个暂时替代描述)
获取线程id的16进制[root@viid-face-snap-0 app]# printf "%x\n" 93
5d
获取线程堆栈信息
由于容器基础镜像为了节省空间去掉了jdk，所以可以将物理机的jdk cp 进入容器[root@localhost too
最低0.47元/天 解锁文章
扫一扫
1259
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
