3.DBLE夯死分析

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的连接分析

从DBLE的连接配置信息来看，DBLE的连接池的连接数量从之前的2000，修改为现在的1000。再回头看前面的现象:连接池空闲连接用完，持续创建大量连接，内存耗尽，夯死，重启，过程反复，我们判定有两个原因导致：

1. JVM本身设置的内存过小，当前4G,用于DBLE的有效内存2.8G,用于新生代内存1.2G。
2. 之前DBLE的连接池设置过大,导致创建连接时消耗了大量的内存，最终内存耗尽夯死。

4.调整建议

       分析当前DBLE服务器内存，还有剩余内存5G,建议将DBLE的JVM内存由原来的4G调整为8G。同时该节点上的服务器的总内存15G，mysql数据库INNODB_BUFFER_POOL_SIZE=10G,该MYSQL节点仅有元数据，可以调小该内存大小。