2 回答

TA貢獻(xiàn)1828條經(jīng)驗(yàn) 獲得超6個(gè)贊
查看您的 GC 日志,CMS 似乎不是您應(yīng)用的正確選擇。
考慮嘗試其他 GC 算法:
并行 GC(它會(huì)給你 10-30 秒的定期暫停,但不是 10 分鐘)
如果你可以升級(jí)到 Java 8,G1 可能是一個(gè)選項(xiàng)(它可能很好也可能很壞——看你的運(yùn)氣了)
如果您想堅(jiān)持使用 CMS ...
...我可以在GC日志中看到有關(guān)“提升失敗”和“并發(fā)模式失敗”的信息,而且GC非常耗時(shí),幾乎需要10分鐘才能完成一個(gè)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 需要很大的舊空間大小來(lái)處理這樣的吞吐量并保持低碎片。不過(guò),您的服務(wù)器似乎已經(jīng)達(dá)到內(nèi)存限制。

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