如何通過負載測試優化JVM和GC

Question

編輯 ：在這個問題已經收到的幾個非常慷慨和有幫助的回答中，很明顯，當我今天早些時候提出這個問題時，我沒有把這個問題的重要部分弄清楚。 到目前為止，我收到的答案更多的是關於優化應用程序和消除代碼級別的瓶頸。 我知道這比嘗試從JVM中獲得額外的3％或5％更重要！

這個問題假設我們已經完成了在代碼級別優化應用程序架構的所有工作。 現在我們想要更多，下一個要看的是JVM級別和垃圾收集; 我已相應更改了問題標題。 再次感謝！

---

我們有一個“管道”式后端架構，消息從一個組件傳遞到下一個組件，每個組件在每個步驟執行不同的過程。

組件存在於Tomcat服務器上部署的WAR文件中。 總共有大約20個組件在管道中，存在於5個不同的Tomcat服務器上（我沒有選擇每個服務器的體系結構或WAR分布）。 我們使用Apache Camel創建組件之間的所有路徑，有效地形成管道的“結締組織”。

我被要求優化運行JVM的每個服務器的GC和一般性能（總共5個）。 我花了幾天時間閱讀GC和性能調優，並且很好地處理了每個不同的JVM選項的作用，堆的組織方式以及大多數選項如何影響JVM的整體性能。

我的想法是，優化每個JVM的最佳方法不是將其優化為獨立的。 我覺得“（我認為可以證明這一點！”）嘗試在本地優化每個JVM而不考慮它將如何與其他服務器（上游和下游）上的其他JVM進行交互將不會產生全局優化的解決方案。

對我來說，從整體上優化整個管道是有意義的。 所以我的第一個問題是： SO是否同意，如果沒有，為什么？

為此，我考慮創建一個LoadTester ，它將生成輸入並將其提供給管道中的第一個端點。 此LoadTester可能還有一個單獨的“ 監視器線程 ”，它將檢查最后一個端點的吞吐量。 然后，我可以進行各種處理，檢查消息的平均端到端傳播時間，斷層前的最大吞吐量等。

LoadTester會一遍又一遍地生成相同的輸入消息模式。 此實驗中的變量將是傳遞給每個Tomcat服務器的啟動選項的JVM選項。 我有一個大約20種不同選項的列表，我想通過JVM，並認為我可以繼續調整它們的值，直到我找到接近最佳的性能。

這可能不是絕對最好的方法，但這是我設計的最佳方式，我已經為這個項目提供了大約一個星期的時間（大約一周）。

第二個問題： SO對此設置有何看法？ SO如何以不同的方式創建“優化解決方案”？

最后但同樣重要的是，我很好奇我可以使用什么樣的指標作為衡量和比較的基礎。 我真的只能想到：

• 找到JVM選項配置，它可以為消息生成最快的平均端到端旅行時間
• 找到生成最大卷吞吐量的JVM選項配置，而不會導致任何服務器崩潰

還有其他人？ 這2個壞的原因是什么？

在回顧了這個劇本之后，我可以看到這可能被視為一個單一的問題，但我真正要問的是如何優化JVM在管道中運行，並隨意切割我的解決方案然而你喜歡它。

提前致謝！

Answer 1

讓我上一層，說我多年前在一個大型C應用程序中做了類似的事情。 它由許多進程組成，這些進程通過互連的硬件交換消息。 我提出了兩步法。

步驟1.在每個過程中，我使用這種技術來擺脫任何浪費的活動。 這需要幾天的采樣，修改代碼，然后重復。 這個想法是有一個鏈條，首先要做的是從鏈接中刪除低效率。

步驟2.此部分費力但有效：生成消息流量的帶時間戳的日志。 將它們合並為一個共同的時間表。 仔細查看特定的消息序列。 你在尋找什么

1. 消息是必要的，還是由於超時或其他可避免的原因導致的重傳？
2. 消息何時被發送，接收和采取行動？ 如果收到和采取行動之間存在重大延遲，那么延遲的原因是什么？ 例如，只是在另一個正在進行I / O的過程中“排隊”的問題是什么？ 是否可以通過不同的流程優先級進行修復？

這項活動花了我一天的時間來生成日志，組合它們，找到加速機會，並修改代碼。 按照這一速度，后10個工作日左右，我找到了/固定的一些問題，並大大提高了速度。

這兩個步驟的共同點是我沒有測量或試圖得到“統計數據”。 如果有什么東西花了太多時間，那么這個事實就會讓一個狡猾的程序員仔細看看正在發生的事情。

Answer 2

我將首先找到為您的硬件/軟件組合指定的最佳推薦jvm值，或者從已經存在的內容開始。

接下來，我將確保我有適當的監控來衡量業務吞吐量和SLA

如果沒有理由，我不會嘗試只調整GC。

首先，您需要找到應用程序中的主要瓶頸。 如果它是I / O綁定，SQL綁定等。

這里的關鍵是測量，識別TOP瓶頸，修復它們並以可重復的負載進行另一次迭代。

HTH ...

Answer 3

在同一台機器上運行多個JVM時，我所知道的最大訣竅是限制GC將使用的核心數量。 否則當一個JVM執行完整GC時會發生什么情況，它會嘗試抓取每個核心，影響所有JVM的性能，即使它們沒有執行GC。 一個建議是將gc線程的數量限制為5/8或更少。 （我不記得它寫在哪里）

---

我認為你應該對系統進行整體測試，以確保服務之間的實際交互。 但是，我認為您可能需要以不同方式調整每項服務。

如果無法更改代碼，則更改命令行選項很有用。 但是，如果您對代碼進行分析和優化，那么除了調整GC參數之外，您可以做出很大的改變（因為您需要再次更改它們）

出於這個原因，我只會將命令行參數更改為最后的手段，之后您可以在應用程序的代碼中進行很少的改進。