rmi full gc問題

在我職業(yè)生涯中進(jìn)行的所有故障排除練習(xí)中，我都感覺到，隨著時(shí)間的推移，我所追尋的錯(cuò)誤在不斷演變，變得越來越卑鄙和丑陋。 也許僅僅是我的年齡開始了。這個(gè)特別的Heisenbug –看起來像這篇帖子一樣，再次讓我清醒了很多，而不是我想要的。

與其他特別令人討厭的錯(cuò)誤一樣，我現(xiàn)在遇到的那個(gè)錯(cuò)誤的癥狀是“有時(shí)系統(tǒng)運(yùn)行緩慢”。 太好了，我已經(jīng)感到脊椎發(fā)麻。 當(dāng)我發(fā)現(xiàn)系統(tǒng)在生產(chǎn)中設(shè)置了一個(gè)簡單的監(jiān)視解決方案來監(jiān)視系統(tǒng)時(shí)，情況變得更好了。 從本質(zhì)上講，它只不過是Pingdom ，它每秒測量一次響應(yīng)時(shí)間，但是延遲圖立即引起了我的注意。

在圖中繪制的響應(yīng)時(shí)間似乎是隨機(jī)的尖峰–每次在藍(lán)月亮中，響應(yīng)開始花費(fèi)的時(shí)間將近10倍。 不久之后，一切又恢復(fù)了正常。

最初的犯罪嫌疑人–看不見常規(guī)的cron工作或昂貴的報(bào)告流程。 存儲(chǔ)監(jiān)視也沒有暴露任何特別丑陋的查詢擊中數(shù)據(jù)庫。 但是在打電話之前，我在應(yīng)用程序配置中添加了更多日志記錄選項(xiàng)，重新啟動(dòng)了整個(gè)程序，并迷惑了自己的行為。

第二天早上，我還有其他事情要看，GC日志等。 十分鐘之內(nèi)，我發(fā)現(xiàn)自己盯著下面的東西：

11.408: [Full GC [PSYoungGen: 192K->0K(48640K)] [ParOldGen: 16324K->14750K(114688K)] 16516K->14750K(163328K) [PSPermGen: 31995K->31637K(64000K)], 0.1543430 secs] [Times: user=0.58 sys=0.00, real=0.16 secs] ... 3613.362: [Full GC [PSYoungGen: 256K->0K(47104K)] [ParOldGen: 15142K->13497K(114688K)] 15398K->13497K(161792K) [PSPermGen: 32429K->32369K(72192K)], 0.1129070 secs] [Times: user=0.51 sys=0.00, real=0.11 secs] ... 7215.278: [Full GC [PSYoungGen: 224K->0K(44544K)] [ParOldGen: 13665K->13439K(114688K)] 13889K->13439K(159232K) [PSPermGen: 32426K->32423K(70144K)], 0.0881450 secs] [Times: user=0.44 sys=0.00, real=0.09 secs] ...

現(xiàn)在，我可以將看似隨機(jī)的性能下降與每次經(jīng)過大約3600秒時(shí)運(yùn)行的Full GC關(guān)聯(lián)起來。 將VisualVM附加到JVM令我感到困惑–沒有證據(jù)表明高內(nèi)存使用率會(huì)導(dǎo)致整個(gè)垃圾收集器運(yùn)行。 與開發(fā)人員核對(duì)后，我確定他們沒有通過cron作業(yè)運(yùn)行顯式GC。 所以我站在那兒，對(duì)GC的常規(guī)性感到困惑。

工程師對(duì)問題感到困惑時(shí)會(huì)怎么做？ 他谷歌 。 就在那里，凝視著我的臉。 與擔(dān)心每小時(shí)進(jìn)行一次完整GC的人員進(jìn)行的逐頁討論，沒有任何明顯的原因。

罪魁禍?zhǔn)?RMI。 顯然，當(dāng)您的應(yīng)用程序通過RMI公開其服務(wù)或通過RMI使用任何服務(wù)時(shí)，您必然會(huì)有一個(gè)額外的垃圾回收周期。 正如RMI文檔所述 ：

“當(dāng)需要確保不導(dǎo)出不可達(dá)的遠(yuǎn)程對(duì)象并及時(shí)進(jìn)行垃圾收集時(shí)，此屬性的值表示Java RMI運(yùn)行時(shí)允許在本地堆的垃圾收集之間允許的最大間隔（以毫秒為單位）。 默認(rèn)值為3600000毫秒（一小時(shí)）。”

暫時(shí)的解決方案是將sun.rmi.dgc.server.gcInterval長度從默認(rèn)的3,600秒增加。 我想知道，當(dāng)RMI過去每分鐘強(qiáng)制一次完整的GC時(shí)，在JDK 6中引入更改之前，情況看起來如何。 考慮到當(dāng)時(shí)所有的EJB狂潮，我猜沒有一個(gè)應(yīng)用程序在性能方面有機(jī)會(huì)。 如果您有遠(yuǎn)古時(shí)代的回憶，也許您可??以了解一下這些應(yīng)用程序如何能夠度過這種瘋狂。

參考： RMI強(qiáng)制Full GC每小時(shí)從JCG合作伙伴 Nikita Salnikov Tarnovski （在Plumbr Blog博客上）運(yùn)行一次 。

翻譯自: https://www.javacodegeeks.com/2013/12/rmi-enforcing-full-gc-to-run-hourly.html

rmi full gc問題

總結(jié)

以上是生活随笔為你收集整理的rmi full gc问题_RMI强制Full GC每小时运行一次的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。