線上應用穩定運行，系統無告警，業務無投訴，都是研發伙伴們所期望的，
但最近生產環境出現一個問題，其中一個實體JVM記憶體爆滿，頻繁FullGC，從而導致出現MySQL獲取不到連接，導致業務無法回應問題，
臨時解決方案：
將這個有問題的實體從注冊中心摘除，以免繼續影響其他業務運行，
第一步查看我們的健康檢查系統，這個實體已經處于不健康的狀態，所有請求都沒回應，
第二步查看Skywalking 鏈路追蹤平臺，幾乎這個實體的呼叫全部超時失敗，
第三步查看運行日志，發現很多MySQL連接獲取超時，服務呼叫失敗等錯誤，
如下所示：
// 報錯1
2021-12-29 14:09:00.222 [http-nio-8030-exec-17] WARN o.s.b.a.j.DataSourceHealthIndicator -DataSource health check failed
org.springframework.jdbc.CannotGetJdbcConnectionException: Failed to obtain JDBC Connection; nested exception is java.sql.SQLTransientConnectionException: HikariCP - Connection is not available, request timed out after 176706ms.
at org.springframework.jdbc.datasource.DataSourceUtils.getConnection(DataSourceUtils.java:82)
at org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:324)
at org.springframework.boot.actuate.jdbc.DataSourceHealthIndicator.getProduct(DataSourceHealthIndicator.java:122)
at org.springframework.boot.actuate.jdbc.DataSourceHealthIndicator.doDataSourceHealthCheck(DataSourceHealthIndicator.java:105)
at org.springframework.boot.actuate.jdbc.DataSourceHealthIndicator.doHealthCheck(DataSourceHealthIndicator.java:100)
at org.springframework.boot.actuate.health.AbstractHealthIndicator.health(AbstractHealthIndicator.java:82)
// 報錯2
org.mybatis.spring.MyBatisSystemException: nested exception is org.apache.ibatis.exceptions.PersistenceException:
### Error querying database. Cause: org.springframework.jdbc.CannotGetJdbcConnectionException: Failed to obtain JDBC Connection; nested exception is java.sql.SQLTransientConnectionException: HikariCP - Connection is not available, request timed out after 112702ms.
第四步同時查看JVM的運行引數，
ps -ef|grep java
輸出：
java -jar -Xloggc:/data/logs/micro-xxxx-service-gc-%t.log -XX:MetaspaceSize=256m -XX:NativeMemoryTracking=detail -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=100m -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCCause -Xmn512m -Xms1024m -Xmx1024m micro-xxxx-service.jar
然后排查JVM GC情況，經查看GC日志發現幾乎每秒都在進行FullGC，
如下圖所示：
經過跟業務和產品確認，我們的用戶量和業務量最近沒有產生過陡增，也就是一直正常跑的應用突然出現了問題，
那根據FullGC頻繁現象，首先懷疑是某個新功能導致記憶體不釋放或直接進入Old區，導致記憶體一直不釋放，最終頻繁Full GC問題，
經過排查出錯日志點開始向前排查，發現有個全表查詢SQL，這個SQL查的表日常資料百萬，大致分析是由這個SQL引起的問題，根據SQL進行分析對應的功能，然后跟產品確認，確實這個功能是最近剛剛上線的新功能，然后馬上組織產品和研發、測驗伙伴確認修改方案，將全表查詢改為帶條件以及增加分頁限制，
個人總結：
- 首先，保留問題現場（運行時堆疊，運行日志），迅速解決影響；
- 監控平臺，鏈路呼叫平臺查看錯誤點；
- 運行日志快速分析出錯點；
- JVM 堆疊、GC情況分析；
- 跟業務和產品確認是否有用戶量或業務量陡增，以及確認是否存在新功能上線；
- 結合運行日志例外和JVM堆疊以及GC情況具體分析；
- 找到問題點，快速修復驗證，發布，
傳送門：
JVM調優- java行程，JVM頻繁GC，導致CPU占用、記憶體占用過高過高定位和排查
JVM-MySQL-Tomcat-服務呼叫，調優相關
生產穩定：SpringBoot-Admin 微服務監控+健康檢查+釘釘告警，附代碼配置
-------------歡迎各位留言交流，如有不正確的地方，請予以指正，【Q:981233589】
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/398638.html
標籤：其他
上一篇：Pulsar原始碼決議
下一篇：Kafka消費者