第七色在线视频,2021少妇久久久久久久久久,亚洲欧洲精品成人久久av18,亚洲国产精品特色大片观看完整版,孙宇晨将参加特朗普的晚宴

為了賬號安全,請及時綁定郵箱和手機立即綁定
已解決430363個問題,去搜搜看,總會有你想問的

高峰請求到來時頻繁且長時間的Java GC,導致應用停止響應10分鐘

高峰請求到來時頻繁且長時間的Java GC,導致應用停止響應10分鐘

胡說叔叔 2023-06-14 16:00:54
我有一個提供在線視頻播放服務的 Java 應用程序。當高峰流量到來時(比如用戶點擊手機推送窗口),GC開銷很大,我在GC日志中可以看到“提升失敗”和“并發(fā)模式失敗”的信息,GC很及時消耗,幾乎需要10分鐘才能完成一個GC周期,這使得應用程序長時間無法響應。我知道問題應該是內(nèi)存使用的錯誤代碼設計,任何人都可以幫助弄清楚如何解決 GC 問題嗎?謝謝。這是我的服務器環(huán)境:cat /etc/redhat-releaseCentOS release 6.8 (Final)free -h             total       used       free     shared    buffers     cachedMem:           31G        31G       302M        16K       260M       6.5G-/+ buffers/cache:        24G       7.1GSwap:         2.0G       564M       1.4Gjava -versionjava version "1.7.0_131"OpenJDK Runtime Environment (rhel-2.6.9.0.el6_8-x86_64 u131-b00)OpenJDK 64-Bit Server VM (build 24.131-b00, mixed mode)這是我原來的 JVM 設置:55634 XmlConfiguration -Xmx22528m -Xms22528m -verbose:gc -XX:NewRatio=3-XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled-Xloggc:/data/logs/jetty/gc.log -XX:GCLogFileSize=10M -XX:NumberOfGCLogFiles=10-XX:+UseGCLogFileRotation -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps-XX:+PrintGCDetails -XX:+DisableExplicitGC -XX:+ScavengeBeforeFullGC-XX:+CMSScavengeBeforeRemark -XX:+UseCMSInitiatingOccupancyOnly-XX:CMSInitiatingOccupancyFraction=70-Djetty.home=/usr/local/jetty-distribution-8.1.16.v20140903我嘗試了一些解決方案,但問題仍然存在。1) 調(diào)整JVM參數(shù):-XX:CMSInitiatingOccupancyFraction=50,使CMS GC更早,為應用程序線程提供更多空閑內(nèi)存。2)調(diào)整JVM參數(shù):-XX:NewRatio=2,讓新生代變大。3)調(diào)整JVM參數(shù):-XX:PermSize=512m,-XX:MaxPermSize=512m,使持久化生成更大。4) 對單臺服務器設置限速器,可以保護下劃線應用。
查看完整描述

2 回答

?
30秒到達戰(zhàn)場

TA貢獻1828條經(jīng)驗 獲得超6個贊

查看您的 GC 日志,CMS 似乎不是您應用的正確選擇。

考慮嘗試其他 GC 算法:

  • 并行 GC(它會給你 10-30 秒的定期暫停,但不是 10 分鐘)

  • 如果你可以升級到 Java 8,G1 可能是一個選項(它可能很好也可能很壞——看你的運氣了)

如果您想堅持使用 CMS ...

...我可以在GC日志中看到有關“提升失敗”和“并發(fā)模式失敗”的信息,而且GC非常耗時,幾乎需要10分鐘才能完成一個GC周期...

您的提升率非常高(100+ MiB/s)

2019-08-17T11:07:38.895+0800: 48789.385: [GC2019-08-17T11:07:38.895+0800: 48789.385: [ParNew: 5098592K->576704K(5190464K), 0.2818390 secs] 16761372K->12241212K(22491968K), 0.2826330 secs] [Times: user=2.2

4 sys=0.00, real=0.28 secs]

2019-08-17T11:07:46.308+0800: 48796.799: [GC2019-08-17T11:07:46.309+0800: 48796.799: [ParNew: 5190464K->576704K(5190464K), 0.4371320 secs] 16854972K->12504773K(22491968K), 0.4380620 secs] [Times: user=2.9

7 sys=0.01, real=0.44 secs]

CMS 需要很大的舊空間大小來處理這樣的吞吐量并保持低碎片。不過,您的服務器似乎已經(jīng)達到內(nèi)存限制。


查看完整回答
反對 回復 2023-06-14
?
一只萌萌小番薯

TA貢獻1795條經(jīng)驗 獲得超7個贊

我終于弄清楚了根本原因。代碼在高峰流量到來時會產(chǎn)生大量對象(超過10GB),導致young GC頻繁發(fā)生,CMS GC回落到SerialOld GC,造成長時間STW。



查看完整回答
反對 回復 2023-06-14
  • 2 回答
  • 0 關注
  • 214 瀏覽
慕課專欄
更多

添加回答

舉報

0/150
提交
取消
微信客服

購課補貼
聯(lián)系客服咨詢優(yōu)惠詳情

幫助反饋 APP下載

慕課網(wǎng)APP
您的移動學習伙伴

公眾號

掃描二維碼
關注慕課網(wǎng)微信公眾號