前言

最近在CF (Cloud Foundry) 云平台上遇到一个比较经典的案例。因为牵扯到JVM （app进程）与数据库连接两大块，稍有不慎，很容易引起不快。

在云环境下，有时候相互扯皮的事蛮多。如果是DB的问题，就会找DB相关部门。关键是如何自证。涉及到职场生存法则，大家都不愿意去背锅，谁背锅，意味着谁要担责。

下边我们看看这个案例。

现场

某一个微服务的Java应用，在部署到云环境下，大概过了几个小时以后，就频繁的宕掉，自动重启，一会儿又宕掉。DevOPS马上发警告邮件，并且给出了一些error message, 甚至相关的callstack也给出来了。

java.sql.SQLTransientConnectionException: HikariPool-******* - Connection is not available, request timed out after 5001ms.,  at com.zaxxer.hikari.pool.HikariPool.createTimeoutException(HikariPool.java:696),  at com.zaxxer.hikari.pool.HikariPool.getConnection(HikariPool.java:197),  at com.zaxxer.hikari.pool.HikariPool.getConnection(HikariPool.java:162),  at com.zaxxer.hikari.HikariDataSource.getConnection(HikariDataSource.java:100),  at org.hibernate.engine.jdbc.connections.internal.DatasourceConnectionProviderImpl.getConnection(DatasourceConnectionProviderImpl.java:122),  at org.hibernate.internal.NonContextualJdbcConnectionAccess.obtainConnection(NonContextualJdbcConnectionAccess.java:38),  at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.acquireConnectionIfNeeded(LogicalConnectionManagedImpl.java:108),  at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.getPhysicalConnection(LogicalConnectionManagedImpl.java:138),  at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.getConnectionForTransactionManagement(LogicalConnectionManagedImpl.java:276),  at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.begin(LogicalConnectionManagedImpl.java:284),  at org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl$TransactionDriverControlImpl.begin(JdbcResourceLocalTransactionCoordinatorImpl.java:246),  at org.hibernate.engine.transaction.internal.TransactionImpl.begin(TransactionImpl.java:83),  at org.springframework.orm.jpa.vendor.HibernateJpaDialect.beginTransaction(HibernateJpaDialect.java:164),  at org.springframework.orm.jpa.JpaTransactionManager.doBegin(JpaTransactionManager.java:421),  at org.springframework.transaction.support.AbstractPlatformTransactionManager.startTransaction(AbstractPlatformTransactionManager.java:400),  at 

就这咋一看，就是connection用完了，拿不到连接了。DB相关人员开始就有点紧张了。难道是DB出问题了？

于是他们单独给DBOps那边开了个ticket，让DBOps直接上AWS PG实例里头查看，一顿查，发现数据库活的好好的呢，在那个时间段，连接数也都还正常。这样的话，他们肯定不会背这锅。

微服务这边，在得知这些结果以后，感觉就有些不太妙了。于是再重新再去查监控：

总数确实也还在那里。单独针对那众目标微服务，再看看细化的情况：

到这里，一看，200个连接瞬间被击垮。看到这里，基本上也就知道，与数据库大概率没什么关系了。应该是应用层出了什么故障了。

什么原因会导致数据库正常但是连接拿不到（不断超时、我们这里是默认5秒还拿不到连接，就算超时，app会自动重启）？

紧接着我们兵分两路：

1、再找到微服务对应的DynaTrace监控

有一个重大发现：

死掉的那一段时间，JVM的Metaspace那一段200MB，全部耗光。但是因为没有CF平台上没有明显的OOM报错，反而容易骗过大家。

2、再细看一下平台那边的Kibana LOG相关细节：

虽然没有：OOM之类的错误提示，却发现有若干下边这样的log:

[33281.379s][error][jvmti] Posting Resource Exhausted event: Metaspace
[33281.379s][error][jvmti] Posting Resource Exhausted event: Metaspace
Resource exhaustion event....
.......

这两条就足以印证jvm的配置参数Metaspace的大小不够，导致最后的问题。

解决方法：将原来的200M调整到300M或250M，就彻底平息了这次事故。

总结:

有的时候，问题不是孤立存在的，从各个层面进行分析，逐个排错，最后还是能找到出问题的原因。如何规避此类事件再次发生，只能进一步加强监控。

以上例为例，因为缺乏对应用层DB Pool的监控预警，比如它很快涨到200，在那一会儿，应该直接就有预警。另一块，针对metaspace耗尽之前也缺乏预警。如果到了90%左右发出预警，那我们仍然有机会重新调整参数，再次部署，一样可以避免问题。

至于引起metaspace上涨的一个主要原因，是因为新部署的app, 增加了另外几个库（合计有几十兆），从而让类的元数据所需空间增加了不少。开发人员平时也很少关注这一块。加起来，刚好快到边界，又没到边界，随着动态类的加载，慢慢又涨了一点，最终导致超标。

关于jvm参数及高优，又是一个非常大的话题：

参考：

https://cloud.tencent.com/developer/article/1408827[1]

https://poonamparhar.github.io/understanding-metaspace-gc-logs[2]

What is Compressed Class Space?[3]

[How to Handle Java Lang OutOfMemoryError Exceptions[4]](https://sematext.com/blog/java-lang-outofmemoryerror/)

上边这张图也能说明一下总的计算方法。Metaspace属于Non-heap的空间。也就是说，在计算总的开销时，它增加了，Java heap那部分就得减小。

JBP_CONFIG_SAP_MACHINE_JRE [memory_calculator_v2: {headroom: 5}]
JBP_CONFIG_SAP_MACHINE_JRE: [memory_calculator_v2: {stack_threads: 600, headroom: 5}]
JBP_CONFIG_JAVA_OPTS      [ java_opts: '-Xss512K -XX:ReservedCodeCacheSize=220M -XX:MaxMetaspaceSize=200M -XX:MaxDirectMemorySize=256M -XX:+DisableExplicitGC -XX:+UseG1GC ' ]
上边用的是SAP自己的JVM(使用OpenJDK结果也一样): SAP在给定4096M总的容器内存时：
4096 - 220 - 200 - 256 - 0.05 * 4096 - 0.5 * 250 = 3090.2 M = 3164364K

当stack_threads调为600时，-Xmx2985164K
4096 - 220 - 200 - 256 - 0.05 * 4096 - 0.5 * 600 = 2915.2 M = 2985164K

围绕的公式就是：

MaxHeapSize = 总内存 - CodeCache - MetaspaceSize- DirectMemory - headroom/100 * 总内存 - Xss * Threadcount。（默认线程数是250）

headroom是预留给容器的本地内存的百分比。

这个公式通常也不见于官方文档，属于平台自己控制的。有了这个公式，就可以自己进行精准拿捏了。

还有一些jvm命令行，可以ssh到container内部执行，进行诊断，如：

1、jps -lvm

app/META-INF/.sap_java_buildpack/sap_machine_jre/bin/jps -lvm
1504 jdk.jcmd/sun.tools.jps.Jps -lvm -Dapplication.home=/home/vcap/app/META-INF/.sap_java_buildpack/sap_machine_jre -Xms8m -Djdk.module.main=jdk.jcmd
7 org.springframework.boot.loader.JarLauncher -Xmx2985164K -Xss512K -XX:ReservedCodeCacheSize=220M -XX:MaxMetaspaceSize=200M -XX:MaxDirectMemorySize=256M -XX:+DisableExplicitGC -XX:+UseG1GC -XX:-UseCompressedClassPointers -Djava.io.tmpdir=/home/vcap/tmp -Dlog4j2.formatMsgNoLookups=true -XX:+UseContainerCpuShares -agentlib:jdwp=transport=dt_socket,address=8000,server=y,suspend=n,onjcmd=y -agentpath:META-INF/.sap_java_buildpack/jvm_kill/jvmkill-1.16.0.RELEASE-trusty.so=printHeapHistogram=1 -XX:ErrorFile= -Dsun.net.inetaddr.ttl=0 -Dsun.net.inetaddr.negative.ttl=0

2、jcmdVM.flags

vcap@ade456f6-f29d-4e37-7b99-0360:~$ app/META-INF/.sap_java_buildpack/sap_machine_jre/bin/jcmd 7 VM.flags
7:
-XX:CICompilerCount=2 -XX:ConcGCThreads=1 -XX:+DisableExplicitGC -XX:ErrorFile= -XX:G1ConcRefinementThreads=1 -XX:G1HeapRegionSize=1048576 -XX:GCDrainStackTargetSize=64 -XX:InitialHeapSize=69206016 -XX:MarkStackSize=4194304 -XX:MaxDirectMemorySize=268435456 -XX:MaxHeapSize=3057647616 -XX:MaxMetaspaceSize=209715200 -XX:MaxNewSize=1833959424 -XX:MinHeapDeltaBytes=1048576 -XX:NonProfiledCodeHeapSize=0 -XX:ProfiledCodeHeapSize=0 -XX:ReservedCodeCacheSize=230686720 -XX:ThreadStackSize=512 -XX:-UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseContainerCpuShares -XX:+UseG1GC 

3、jcmdGC.heap_info

e456f6-f29d-4e37-7b99-0360:~$ app/META-INF/.sap_java_buildpack/sap_machine_jre/bin/jcmd 7 GC.heap_info
7:
 garbage-first heap   total 1166336K, used 204288K [0x0000000749c00000, 0x0000000800000000)
  region size 1024K, 113 young (115712K), 18 survivors (18432K)
 Metaspace       used 116011K, capacity 117599K, committed 117704K, reserved 118784K

在云环境下，PG的稳定性还是很牛气的。稳如老狗一点也不为过，除了表膨胀、空间肿胀等需要来加看管，很大一部分云平台都给你扛过去了。当然，常规的性能优化与调整也是必要的，应用层开发人员配合DBA，总能找到比较舒服的解决方案。

参考资料

[1]https://cloud.tencent.com/developer/article/1408827: https://cloud.tencent.com/developer/article/1408827

[2]https://poonamparhar.github.io/understanding-metaspace-gc-logs: https://poonamparhar.github.io/understanding-metaspace-gc-logs/

[3]What is Compressed Class Space?: https://stuefe.de/posts/metaspace/what-is-compressed-class-space/

[4][How to Handle Java Lang OutOfMemoryError Exceptions: https://sematext.com/blog/java-lang-outofmemoryerror/