2 回答

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)存限制。

TA貢獻1795條經(jīng)驗 獲得超7個贊
我終于弄清楚了根本原因。代碼在高峰流量到來時會產(chǎn)生大量對象(超過10GB),導致young GC頻繁發(fā)生,CMS GC回落到SerialOld GC,造成長時間STW。
添加回答
舉報