這個(gè)故事可以追溯到至少十年之前，當(dāng)時(shí)我第一次接觸PHB時(shí)遇到一個(gè)問(wèn)題：“在生產(chǎn)部署中，我們需要購(gòu)買(mǎi)多大服務(wù)器”。 我們正在構(gòu)建的新的，閃亮的系統(tǒng)距離生產(chǎn)開(kāi)始還有9個(gè)月的時(shí)間，顯然該公司已承諾提供包括硬件在內(nèi)的整個(gè)解決方案。

天哪，我有麻煩了。 憑借幾年的經(jīng)驗(yàn)，我?guī)缀蹩梢詳S骰子了。 盡管我確信我完全缺乏信心是顯而易見(jiàn)的，但我仍然不得不想出答案。 四個(gè)小時(shí)的谷歌搜索之后，我回想起坐在那里，同樣的問(wèn)題仍然徘徊在我眼花bed亂的臉前：

“如何估算對(duì)計(jì)算能力的需求？”

在本文中，我為您提供了有關(guān)如何估算全新Java應(yīng)用程序的內(nèi)存需求的粗略指導(dǎo)，從而開(kāi)始了這一主題。 對(duì)于不耐煩的用戶，答案將是從大約等于5 x [Live Data占用的內(nèi)存量]的內(nèi)存開(kāi)始，然后從那里開(kāi)始進(jìn)行微調(diào)。 對(duì)于那些對(duì)背后的邏輯更加好奇的人，請(qǐng)留在我身邊，我將帶您進(jìn)行推理。

首先，我只能建議避免在沒(méi)有詳細(xì)信息的情況下回答這樣的問(wèn)題。 您的答案必須基于性能要求，因此，即使沒(méi)有先澄清這些要求，也不要開(kāi)始。 我的意思不是太含糊的“系統(tǒng)需要支持700個(gè)并發(fā)用戶”，而是考慮到數(shù)據(jù)量和使用模式，關(guān)于延遲和吞吐量的更為具體的描述。 也不要忘記預(yù)算-我們所有人都可以夢(mèng)到亞毫秒級(jí)的延遲，但是那些沒(méi)有HFT銀行骨干預(yù)算的人-不幸的是，這只是一個(gè)夢(mèng)想。

現(xiàn)在，假設(shè)您已具備這些要求。 下一站將是創(chuàng)建模擬用戶行為的負(fù)載測(cè)試腳本。 如果現(xiàn)在可以同時(shí)啟動(dòng)這些腳本，那么您已經(jīng)為答案奠定了基礎(chǔ)。 正如您可能已經(jīng)猜到的那樣，下一步涉及我們通常建議的不要猜測(cè)的建議。 但是要注意。

實(shí)時(shí)數(shù)據(jù)大小

即，我們尋求最佳內(nèi)存配置需要捕獲實(shí)時(shí)數(shù)據(jù)大小。 捕獲了這一點(diǎn)之后，我們就可以進(jìn)行微調(diào)的基線配置了。

如何定義實(shí)時(shí)數(shù)據(jù)大小？ Charlie Hunt和Binu John在他們的“ Java Performance ”書(shū)中給出了以下定義：

實(shí)時(shí)數(shù)據(jù)大小是在穩(wěn)定狀態(tài)下運(yùn)行應(yīng)用程序所需的一組長(zhǎng)期對(duì)象消耗的堆大小。

有了定義，我們準(zhǔn)備在打開(kāi)GC日志記錄的情況下對(duì)應(yīng)用程序運(yùn)行負(fù)載測(cè)試（-XX：+ PrintGCTimeStamps -Xloggc：/tmp/gc.log -XX：+ PrintGCDetails），并可視化日志（使用例如gcviewer的幫助）來(lái)確定應(yīng)用程序達(dá)到穩(wěn)定狀態(tài)的時(shí)間。 您所追求的類(lèi)似于以下內(nèi)容：

我們可以在熟悉的雙鋸齒圖形中看到GC在次要GC和Full GC運(yùn)行中都能完成工作。 在第21秒運(yùn)行第一個(gè)完整GC之后，此特定應(yīng)用程序似乎已達(dá)到穩(wěn)定狀態(tài)。 但是，在大多數(shù)情況下，需要10-20次完整GC運(yùn)行才能發(fā)現(xiàn)趨勢(shì)變化。 在運(yùn)行了四個(gè)完整的GC之后，我們可以估計(jì)實(shí)時(shí)數(shù)據(jù)大小大約等于100MB。

前面提到的Java Performance書(shū)現(xiàn)在表明，在典型的Java EE應(yīng)用程序中，“實(shí)時(shí)數(shù)據(jù)大小”與最佳內(nèi)存配置參數(shù)之間存在很強(qiáng)的相關(guān)性。 該領(lǐng)域的證據(jù)也支持他們的建議：

將最大堆大小設(shè)置為3-4 x [實(shí)時(shí)數(shù)據(jù)大小]

因此，對(duì)于當(dāng)前的應(yīng)用程序，我們應(yīng)該將-Xmx設(shè)置為介于300m和400m之間，以進(jìn)行初始性能測(cè)試，然后從那里開(kāi)始進(jìn)行測(cè)試。

我們對(duì)本書(shū)中的其他建議有不同的看法，建議將最大永久代大小設(shè)置為1.2-1.5 x [永久代的實(shí)時(shí)數(shù)據(jù)大小]，將-XX：NewRatio設(shè)置為[[實(shí)時(shí)數(shù)據(jù)大小]。 目前，我們正在收集更多數(shù)據(jù)以確定正相關(guān)性是否存在，但在此之前，我建議您將生存和簡(jiǎn)化配置的決定基于監(jiān)視分配率。

您現(xiàn)在可能會(huì)問(wèn)為什么要打擾。 的確，有兩個(gè)原因不引起立即關(guān)注：

• 在撰寫(xiě)本文時(shí)，8G內(nèi)存芯片的價(jià)格不到100美元
• 虛擬化，特別是在使用大型供應(yīng)商（例如Amazon AWS）時(shí)，使調(diào)整容量變得容易

這兩個(gè)原因都是部分有效的，并且絕對(duì)減少了精確配置的需求。 但是他們兩個(gè)仍然把你置于危險(xiǎn)區(qū)域

• 當(dāng)“以防萬(wàn)一”投入大量?jī)?nèi)存時(shí)，您很可能會(huì)顯著影響延遲-進(jìn)入8G以上的堆時(shí)，引入跨越數(shù)十秒的Full GC暫停非常容易。
• 當(dāng)以“稍后調(diào)整”的思想進(jìn)行過(guò)度配置時(shí)，“后期”部分趨向于永不滿足。 正因?yàn)槿绱?#xff0c;我面對(duì)了許多在預(yù)置環(huán)境上運(yùn)行的應(yīng)用程序。 例如，我發(fā)現(xiàn)在Amazon EC2 m1.xlarge實(shí)例上運(yùn)行的上述應(yīng)用程序使該公司每年每實(shí)例花費(fèi)4,200美元。 將其轉(zhuǎn)換為m1.small可以使實(shí)例的費(fèi)用減少到520美元。 如果您的部署規(guī)模很大，則可以從您的運(yùn)營(yíng)預(yù)算中看到8倍的成本降低，請(qǐng)相信我。

摘要

不幸的是，我仍然看到太多的決策完全像十年前我被迫做的那樣。 這會(huì)導(dǎo)致容量規(guī)劃不足和過(guò)度規(guī)劃，兩者都是同樣糟糕的選擇，尤其是在您無(wú)法享受虛擬化優(yōu)勢(shì)的情況下。

我對(duì)我很幸運(yùn)，但是您可能不會(huì)與您的客戶見(jiàn)面，所以我只建議您使用本文中描述的簡(jiǎn)單框架進(jìn)行實(shí)際計(jì)劃。

參考： 如何估算內(nèi)存消耗？ 由我們的JCG合作伙伴 Nikita Salnikov Tarnovski在Plumbr Blog博客上獲得。

翻譯自: https://www.javacodegeeks.com/2014/01/how-to-estimate-memory-consumption.html

總結(jié)

以上是生活随笔為你收集整理的如何估算内存消耗？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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