有幾種方法可以改善您的產(chǎn)品。 一種方法是仔細(xì)跟蹤用戶的體驗(yàn)并在此基礎(chǔ)上進(jìn)行改進(jìn)。 我們確實(shí)自己應(yīng)用了此技術(shù)，并再次花了一些時(shí)間查看不同的數(shù)據(jù)

除了我們追求的許多其他方面之外，我們還提出了一個(gè)問題“延遲GC觸發(fā)應(yīng)用程序的最壞情況是什么”。 為了回答這個(gè)問題，我們分析了過去兩個(gè)月中來自312個(gè)連接Plumbr Agent的JVM的數(shù)據(jù)。 結(jié)果很有趣，我們決定與您分享結(jié)果：

在X軸上，此JVM中有最大的暫停長度，分為多個(gè)存儲(chǔ)區(qū)。 在Y軸上，有特定數(shù)量的最大暫停的應(yīng)用程序。 使用上面的數(shù)據(jù)，我們可以例如對被監(jiān)控的312個(gè)JVM聲明以下內(nèi)容：

• 57個(gè)JVM（18％）設(shè)法使GC停頓了一下，最大停頓時(shí)間不到256ms
• 73個(gè)JVM（23％）面臨的最大GC暫停時(shí)間為1024毫秒至4095毫秒
• 由于GC，105個(gè)JVM（33％）停止了應(yīng)用程序線程4秒鐘或更長時(shí)間。
• 43個(gè)JVM（ 14％ ）面臨的最大GC暫停時(shí)間超過16秒
• 18個(gè)JVM（ 6％）包含GC暫停時(shí)間超過一分鐘
• 由于垃圾回收暫停，當(dāng)前記錄保存者設(shè)法將所有應(yīng)用程序線程停止了16分鐘以上。

我們確實(shí)承認(rèn)我們的數(shù)據(jù)可能存在偏見-Plumbr最終監(jiān)視的JVM更可能遭受觸發(fā)更長GC暫停的性能問題。 因此，您需要花些力氣才能得出這些結(jié)果，但是總的來說，發(fā)現(xiàn)仍然很有趣。 畢竟，對于那里的大多數(shù)應(yīng)用程序，不能認(rèn)為延遲增加了數(shù)十秒。

我們有幾個(gè)假設(shè)，說明情況為何如此糟糕：

• 在第一種情況下，工程師甚至都沒有意識(shí)到他們的應(yīng)用程序性能如此差。 無法訪問GC日志并與客戶支持隔離開來可能完全使那些可能會(huì)改善情況的人員隱瞞問題
• 第二種情況是人們在努力重現(xiàn)問題。 與往常一樣，尋求解決方案的第一步是在可以進(jìn)行進(jìn)一步實(shí)驗(yàn)的環(huán)境中構(gòu)建可重現(xiàn)的測試用例。 當(dāng)持久的GC暫停僅在生產(chǎn)環(huán)境中發(fā)生時(shí)，提出一個(gè)解決方案是一項(xiàng)艱巨的任務(wù)。
• 第三組問題落在意識(shí)到問題的工程師的肩膀上，他們甚至可以隨意重現(xiàn)行為，但不知道如何實(shí)際改善情況。 調(diào)優(yōu)GC是一項(xiàng)棘手的任務(wù)，需要大量有關(guān)JVM內(nèi)部的知識(shí)，因此，在這種情況下，大多數(shù)工程師會(huì)陷入困境。

好消息是，我們正在努力使所有這些原因都過時(shí)-Plumbr發(fā)現(xiàn)表現(xiàn)不佳的GC問題，在發(fā)現(xiàn)這些問題時(shí)提醒您，并且更好地為您提供了量身定制的解決方案，以改善行為。 因此，您無需花費(fèi)數(shù)周的反復(fù)試驗(yàn)，就可以在幾分鐘內(nèi)浮出水面并解決這些案件。

翻譯自: https://www.javacodegeeks.com/2014/10/revealing-the-length-of-garbage-collection-pauses.html

總結(jié)

以上是生活随笔為你收集整理的揭示垃圾收集暂停的时间长度的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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