rmi full gc問題

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

與其他特別令人討厭的錯誤一樣，我現在遇到的那個錯誤的癥狀是“有時系統運行緩慢”。 太好了，我已經感到脊椎發麻。 當我發現系統在生產中設置了一個簡單的監視解決方案來監視系統時，情況變得更好了。 從本質上講，它只不過是Pingdom ，它每秒測量一次響應時間，但是延遲圖立即引起了我的注意。

在圖中繪制的響應時間似乎是隨機的尖峰–每次在藍月亮中，響應開始花費的時間將近10倍。 不久之后，一切又恢復了正常。

最初的犯罪嫌疑人–看不見常規的cron工作或昂貴的報告流程。 存儲監視也沒有暴露任何特別丑陋的查詢擊中數據庫。 但是在打電話之前，我在應用程序配置中添加了更多日志記錄選項，重新啟動了整個程序，并迷惑了自己的行為。

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

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] ...

現在，我可以將看似隨機的性能下降與每次經過大約3600秒時運行的Full GC關聯起來。 將VisualVM附加到JVM令我感到困惑–沒有證據表明高內存使用率會導致整個垃圾收集器運行。 與開發人員核對后，我確定他們沒有通過cron作業運行顯式GC。 所以我站在那兒，對GC的常規性感到困惑。

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

罪魁禍首-RMI。 顯然，當您的應用程序通過RMI公開其服務或通過RMI使用任何服務時，您必然會有一個額外的垃圾回收周期。 正如RMI文檔所述 ：

“當需要確保不導出不可達的遠程對象并及時進行垃圾收集時，此屬性的值表示Java RMI運行時允許在本地堆的垃圾收集之間允許的最大間隔（以毫秒為單位）。 默認值為3600000毫秒（一小時）。”

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

參考： RMI強制Full GC每小時從JCG合作伙伴 Nikita Salnikov Tarnovski （在Plumbr Blog博客上）運行一次 。

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

rmi full gc問題

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。