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。再回头看前面的现象:连接池空闲连接用完,持续创建大量连接,内存耗尽,夯死,重启,过程反复,我们判定有两个原因导致:
- JVM本身设置的内存过小,当前4G,用于DBLE的有效内存2.8G,用于新生代内存1.2G。
- 之前DBLE的连接池设置过大,导致创建连接时消耗了大量的内存,最终内存耗尽夯死。
4.调整建议
分析当前DBLE服务器内存,还有剩余内存5G,建议将DBLE的JVM内存由原来的4G调整为8G。同时该节点上的服务器的总内存15G,mysql数据库INNODB_BUFFER_POOL_SIZE=10G,该MYSQL节点仅有元数据,可以调小该内存大小。