网站开发电商项目的成本管理怎么写,品牌建设教材,有了源码怎么做软件,搜索引擎优化学习前言
最近在CF (Cloud Foundry) 云平台上遇到一个比较经典的案例。因为牵扯到JVM #xff08;app进程#xff09;与数据库连接两大块#xff0c;稍有不慎#xff0c;很容易引起不快。
在云环境下#xff0c;有时候相互扯皮的事蛮多。如果是DB的问题#xff0c;就会找DB… 前言
最近在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:ReservedCodeCacheSize220M -XX:MaxMetaspaceSize200M -XX:MaxDirectMemorySize256M -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。默认线程数是250headroom是预留给容器的本地内存的百分比。
这个公式通常也不见于官方文档属于平台自己控制的。有了这个公式就可以自己进行精准拿捏了。
还有一些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.mainjdk.jcmd
7 org.springframework.boot.loader.JarLauncher -Xmx2985164K -Xss512K -XX:ReservedCodeCacheSize220M -XX:MaxMetaspaceSize200M -XX:MaxDirectMemorySize256M -XX:DisableExplicitGC -XX:UseG1GC -XX:-UseCompressedClassPointers -Djava.io.tmpdir/home/vcap/tmp -Dlog4j2.formatMsgNoLookupstrue -XX:UseContainerCpuShares -agentlib:jdwptransportdt_socket,address8000,servery,suspendn,onjcmdy -agentpath:META-INF/.sap_java_buildpack/jvm_kill/jvmkill-1.16.0.RELEASE-trusty.soprintHeapHistogram1 -XX:ErrorFile -Dsun.net.inetaddr.ttl0 -Dsun.net.inetaddr.negative.ttl02、jcmdVM.flags
vcapade456f6-f29d-4e37-7b99-0360:~$ app/META-INF/.sap_java_buildpack/sap_machine_jre/bin/jcmd 7 VM.flags
7:
-XX:CICompilerCount2 -XX:ConcGCThreads1 -XX:DisableExplicitGC -XX:ErrorFile -XX:G1ConcRefinementThreads1 -XX:G1HeapRegionSize1048576 -XX:GCDrainStackTargetSize64 -XX:InitialHeapSize69206016 -XX:MarkStackSize4194304 -XX:MaxDirectMemorySize268435456 -XX:MaxHeapSize3057647616 -XX:MaxMetaspaceSize209715200 -XX:MaxNewSize1833959424 -XX:MinHeapDeltaBytes1048576 -XX:NonProfiledCodeHeapSize0 -XX:ProfiledCodeHeapSize0 -XX:ReservedCodeCacheSize230686720 -XX:ThreadStackSize512 -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/
