3.DBLE夯死分析

最新推荐文章于 2025-12-16 17:32:52 发布

原创最新推荐文章于 2025-12-16 17:32:52 发布 · 488 阅读

10 ·

CC 4.0 BY-SA版权

文章标签：

#中间件

DBLE中间件运维专栏收录该内容

4 篇文章

订阅专栏

文章描述了一段关于DBLE服务在使用过程中频繁因内存溢出（OutOfMemoryError:GCoverheadlimitexceeded）而宕机的故障日志，涉及连接池过度使用、JVM内存设置不足和慢SQL分析。作者提出应调整JVM内存并优化MySQL配置以解决问题。

1.业务突然使用时DBLE夯死

日志分析

2023-12-08 11:24:53  java.lang.OutOfMemoryError: GC overhead limit exceeded
2023-12-08 11:25:40 --java.lang.OutOfMemoryError:GC overhead limit exceeded
2023-12-08 11:26:26 --持续创建连接
2023-12-08 11:27:41 --java.lang.OutOfMemoryError: GC overhead limit exceeded
2023-12-08 12:11:42 --java.lang.OutOfMemoryError:GC overhead limit exceeded
2023-12-08 12:10:01  Server daemon died!
2023-12-08 12:10:01  java.lang.OutOfMemoryError: GC overhead limit exceeded
2023-12-08 12:11:45  JVM appears hung: Timed out waiting for signal from JVM  --夯死。
2023-12-08 12:11:50  --(1)DBLE重启。
2023-12-08 12:34     --重新java.lang.OutOfMemoryError:GC overhead limit exceeded
2023-12-08 12:55:06  --重新java.lang.OutOfMemoryError:GC overhead limit exceeded
2023-12-08 12:56:41  --cannot reached 
2023-12-08 13:05:14  --创建大量的连接
2023-12-08 13:19:37  --163亿行表扫描结束,运行:9.38天。
2023-12-08 13:21:27  --(2)DBLE重启。
2023-12-08 13:28:12  --163亿行表扫描结束,运行:9.54天。
2023-12-08 13:47:20  --cannot reached 
2023-12-08 13:48:17  --重新java.lang.OutOfMemoryError:GC overhead limit exceeded
2023-12-08 13:49:50  Server daemon died!
2023-12-08 13:50:35  --(3)DBLE重启。
2023-12-08 14:26:04  --又是大量的创建连接
2023-12-08 14:48:12  --(4)DBLE重启。
2023-12-08 15:05:53  --SLAVE STOP; 
2023-12-08 17:34:17  --SLAVE START  --我启动过一次。
2023-12-08 17:36:41  --重新java.lang.OutOfMemoryError:GC overhead limit exceeded
2023-12-08 17:41:37  --创建大量连接
2023-12-08 17:41:13  Server daemon died!
2023-12-08 17:43:07  --(5)DBLE重启
2023-12-08 18:16:58  --SLAVE 异常 
2023-12-08 18:18:52  --(6)DBLE重启

2023-12-08 21:40:16  --又是大量创建连接
2023-12-09 00:15:26  --java.lang.OutOfMemoryError: GC overhead limit exceeded
2023-12-09 00:17:05  --Server daemon died!
2023-12-09 00:17:05  --java.lang.OutOfMemoryError: GC overhead limit exceeded
2023-12-09 00:18:06  --(7)重启 Server startup successfully. dble version is [5.6.29-dble-2.19.09.0
2023-12-09 11:03:46  --java.lang.OutOfMemoryError: GC overhead limit exceeded
2023-12-09 11:07:50  --java.lang.OutOfMemoryError: GC overhead limit exceeded
2023-12-09 13:41:14  --java.lang.OutOfMemoryError: GC overhead limit exceeded
2023-12-09 13:52:37  --java.lang.OutOfMemoryError: GC overhead limit exceeded
2023-12-09 13:56:31  --Exception in thread "complexQueryExecutor78" java.lang.OutOfMemoryError: GC overhead limit exceeded
2023-12-09 13:59:14  --Exception in thread "backendBusinessExecutor12" java.lang.OutOfMemoryError: GC overhead limit exceeded

通过以上日志可以看出一个现象:
每次在DBLE夯死前都是伴随着连接池没有空闲连接，创建大量的连接，等到创建到一定的量，紧接着出现OOM(jvm内存溢出)，紧接着DBLE夯死，然后重启。
从2023-12-08 11:24:53 开始出现内存溢出到2023-12-09 13:59:14 总共重启过至少7次，2023-12-08当天总共重启过6次。
这其中有两个慢SQL,每个运行时长超过9天,但是在报错误前，我们也分析了即使有慢SQL,但并未报错。所以我们推测DBLE夯死和慢SQL无关。
猜测:
是因为并发上来了导致创建大量的连接，消耗较大的JVM内存,导致JVM内存溢出,最终DBLE夯死,然后重启。

2.DBLE的JAVA内存分析

wrapper.java.additional.10=-Xmx12G
wrapper.java.additional.11=-Xms6G
wrapper.java.additional.12=-XX:MaxDirectMemorySize=2G
# Initial Java Heap Size (in MB)
wrapper.java.initmemory=4096
# Maximum Java Heap Size (in MB)
wrapper.java.maxmemory=4096

 -XX:+AggressiveOpts 
 -XX:InitialHeapSize=4294967296 
 -XX:+ManagementServer 
 -XX:MaxDirectMemorySize=2147483648 
-XX:MaxHeapSize=4294967296 
 -XX:+PrintGC 
 -XX:+PrintGCDateStamps 
 -XX:+PrintGCDetails 
 -XX:+PrintGCTimeStamps 
 -XX:+PrintHeapAtGC 
 -XX:+UseCompressedClassPointers 
 -XX:+UseCompressedOops 
 -XX:+UseParallelGC

{Heap before GC invocations=3 (full 1):
 PSYoungGen      total 1223168K, used 1048576K [0x000000076ab00000, 0x00000007c0000000, 0x00000007c0000000)
  eden space 1048576K, 100% used [0x000000076ab00000,0x00000007aab00000,0x00000007aab00000)
  from space 174592K, 0% used [0x00000007aab00000,0x00000007aab00000,0x00000007b5580000)
  to   space 174592K, 0% used [0x00000007b5580000,0x00000007b5580000,0x00000007c0000000)
 ParOldGen       total 2796544K, used 17825K [0x00000006c0000000, 0x000000076ab00000, 0x000000076ab00000)
  object space 2796544K, 0% used [0x00000006c0000000,0x00000006c11685c8,0x000000076ab00000)
 Metaspace       used 26302K, capacity 26502K, committed 26880K, reserved 1073152K
  class space    used 2905K, capacity 2996K, committed 3072K, reserved 1048576K

从以上信息可以看出:
(1)JVM新生代内存是1223168K=1.2G左右
(2)JVM总内存:4G（最大最小都是4G）
(3)JVM给到DBLE用到的内存=4-1.2=2.8G.
总体来看,JVM给到dble可以使用的内存在2.8G左右，偏小

3.DBLE的连接分析