如何估算內存消耗

        英文原文：How to Estimate Memory Consumption

        Performance Zone 是由 New Relic 和 AppDynamics 支持的。New Relic 和 AppDynamics 作為 APM 領域的領導者，有著備受矚目的用戶并為用戶消減大量成本。

        這個故事至少可以追溯到十年前，當我第一次接觸到 PHB，遇到了這樣一個問題——“為了產品部署我們應該購買多大的服務器”。這個嶄新的系統上線已經九個月了。顯然公司已經承諾提供整套的解決方案，包括硬件。

        哦，乖乖，我是陷入麻煩之中了嗎？我有幾年的經驗，我倒是可以試一試。雖然我我完全沒有信心，但我還是要解決這個問題。經過在谷歌上四個小時的搜索，我依然坐在那里，擺在我面前的還是那個令我感到困惑的問題：“如何估算計算容量呢？”。

        在這篇文章中我通過給你幾個大致的綱領來開展這個主題，這些綱領是關于如何估計你的那個全新的 Java 應用所需的內存。對于性急的人來講，答案大概約等于 5x（內存通過實時數據消耗量），并從那里開始微調。而對于那些對背后邏輯更感興趣的人，請隨我一起，我會引導你完成推理。

        首先，在沒有詳細信息之前，我不能用簡單的幾句話來回答這個問題。你的答案必須是依據性能要求而來的，所以剛開始的時候首先要澄清這點。我并不 是說要用很含糊不清的方式，譬如“這個系統需要在線支持 700 個用戶”，但還有很多更具體的關于延遲和吞吐量的細節，還要考慮到大量數據，以及使用模式。預算也不應當被遺忘，我們都幻想著亞毫秒級的延遲，但是沒有 HTF 銀行那樣的雄厚資金支持的話，很不幸，它終將只是一個夢想。

        現在，我們假設你有了一些需求，下一步是創建負載測試腳本來模擬用戶的行為。如果你可以同時在線啟動這些的腳本，你就已經為獲取答案建立基礎了。正如你猜想的那樣，下一步是測試，而不是瞎猜，但是會有一個警告。

        實時數據的大小

        也就是說，最佳內存配置需要捕獲實時數據大小。捕獲到這些，我們就有了微調的基礎。

        如何定義實時數據的大小？Charlie Hunt 和 Binu John 在他們《Java 性能》一書中給出的定義如下：

        實時數據的大小是由設置在其穩定狀態運行應用程序所需的長期消耗對象的堆大小。

        有了這個定義，我們在 GC 日志的打開的情況下就可以對應用程序進行負載測試（-XX：+PrintGCTimeStamps-Xloggc:/tmp/gc.log-XX:+PrintGCDetails）和可視化的日志（例如在 gcviewer 的幫助下）來確定應用程序達到穩定狀態的時間。接下來你所看到的類似于下圖：

        我們可以看到，GC 進行了 minor GC 和 full GC，有個熟悉的雙鋸齒形的圖形。在第 21 秒第一次 full GC 完之后，這個特殊的應用程序看起來已經達到一個穩定的狀態了。然而，在大多數情況下，觀察到變化的趨勢需要 10-20 次 full GC 的運行。經過四個 full GC，我們可以估算出實時數據大小約等于 100MB。

        上述《Java 性能》這本書表明在一個經典的 Java EE 應用程序中，實時數據大小和最佳內存配置參數之間有很強的相關性，這個領域的證據也支持他們的建議:

        設置最大堆大小為3-4X (實時數據大小)。

        所以，就我們手中應用程序而言，我們應該將-Xmx 設置為 300M 和 400M 之間進行初始性能測試，并從這里進行調試。

        我們對于書上給出的其他建議，建議設置最大的永久代大小為 1.2-1.5x（永久代中實時數據大小）以及-XX：NewRatio 設置為1-1.5x 的（實時數據大小）。目前，我們正在收集更多的數據來確定正相關關系是否存在，但是在那之前，我建議你在配置生存者空間和伊甸園空間時，需要監視到的分配 率來作決策。

        你可能會問為什么要煩惱這些問題呢？事實上，有兩個原因讓你不需要考慮這個問題：

        （1）在寫這篇文章的時候，8G 內存芯片只售 100 美元

        （2）虛擬化，尤其是大型供應商如亞馬遜的 AWS 使得調試變得更為簡單

        這兩個原因的有效性都是片面的，而且明確地減少了精確調配所需。但是它們仍然能夠將你拉入危險區域。

        （1）當有大量內存空間時，你很有可能會對延遲造成重大影響，8G 以上的堆非常容易進行 full GC，這將可能停頓超過數十秒。

        （2）過度配置時總是會有“稍后調整”的心態，而這“稍后”可能永遠就不會再調整了。我見過大量的應用只是因為這個原因，運行在過度配置的環境 中。例如，前面所提到的應用程序，我發現在亞馬遜 EC2 上 m1.xlarge 實例運行成本是每個實例 4200 美元/年，若將其轉換成 m1.small 就只需 520 美元。如果你的部署夠大，從業務預算中就可以降低 8 倍成本，這一點上請相信我。

        總結

        不幸的是，我依然看到很多決策同我十年前被迫做的極其相似，這導致了規劃不足或者過度，這兩者都是很差勁的選擇。特別是你甚至不能享受虛擬化帶來的好處。

        你可能不能僅憑猜測就獲得成功，所以我只能建議你使用這篇文章描述的簡單框架之前，要有實際的計劃。如果你很喜歡這些內容，我推薦你關注我們在 推ter 上的關于性能調優的建議。

        翻譯： ImportNew.com - 范琦琦

        譯文鏈接： http://www.importnew.com/10570.html