aws高額賬單

大多數(shù)性能問題可以通過幾種不同的方式解決。 多數(shù)人都容易理解和應(yīng)用許多適用的解決方案。 一些解決方案（例如從JVM管理的堆中刪除某些數(shù)據(jù)結(jié)構(gòu)）更加復(fù)雜。 因此，如果您不熟悉此概念，我建議您繼續(xù)學(xué)習(xí)我們最近如何減少應(yīng)用程序的延遲以及如何將Amazon AWS費用減少一半。

我將從解釋需要解決方案的上下文開始。 如您所知， Plumbr密切關(guān)注每次用戶交互。 這是使用部署在處理交互的應(yīng)用程序節(jié)點旁邊的代理來完成的。

這樣做時，Plumbr代理會從此類節(jié)點捕獲不同的事件。 所有事件都發(fā)送到中央服務(wù)器，并組成我們稱為事務(wù)的事務(wù)。 事務(wù)包含多個屬性，包括：

• 交易的開始和結(jié)束時間戳；
• 執(zhí)行交易的用戶的身份；
• 執(zhí)行的操作（將項目添加到購物車，創(chuàng)建新發(fā)票等）；
• 該操作所屬的應(yīng)用程序；

在我們面臨的特定問題的背景下，重要的是概述僅將對實際值的引用存儲為事務(wù)的屬性。 例如，不是存儲用戶的實際身份（例如電子郵件，用戶名或社會保險號），而是在交易本身旁邊存儲對此類身份的引用。 因此，事務(wù)本身可能如下所示：

ID 開始 結(jié)束 應(yīng)用 操作方式 用戶

＃1	12:03:40	12:05:25	＃11	＃222	＃3333
＃2	12:04:10	12:06:00	＃11	＃223	＃3334

這些參考與對應(yīng)的人類可讀值對應(yīng)。 通過這種方式，可以維護每個屬性的鍵-值映射關(guān)系，從而可以將ID為＃3333和＃3334的用戶分別解析為John Smith和Jane Doe。

這些映射在運行時期間使用，當訪問事務(wù)的查詢將用人類可讀的引用數(shù)據(jù)替換引用時：

ID 開始 結(jié)束 應(yīng)用 操作方式 用戶

＃1	12:03:40	12:05:25	www.example.com	/登錄	約翰·史密斯
＃2	12:04:10	12:06:00	www.example.com	/購買	簡·多伊

天真的解決方案

我敢打擾，我們的讀者中的任何人都可以閉上眼睛來想出一個簡單的解決方案。 選擇一個自己喜歡的java.util.Map實現(xiàn)，將鍵值對加載到Map并在查詢期間查找引用的值。

當我們發(fā)現(xiàn)我們選擇的基礎(chǔ)架構(gòu)（具有存儲在Kafka主題中的查找數(shù)據(jù)的Druid存儲）已經(jīng)通過Kafka查找開箱即用地支持此類Maps時，覺得容易的事情變得微不足道。

問題

幼稚的方法為我們服務(wù)了一段時間。 一段時間后，隨著查找映射的大小增加，需要查找值的查詢開始花費越來越多的時間。

我們在吃自己的狗糧并使用Plumbr監(jiān)視Plumbr本身時注意到了這一點。 我們開始看到在Druid Historical節(jié)點上，GC暫停越來越頻繁且更長，為查詢提供服務(wù)并解決查找問題。

顯然，一些最有問題的查詢必須從地圖中查找超過100,000個不同的值。 這樣做的時候，查詢被GC啟動打斷，并且超出了以前不到100ms的查詢持續(xù)時間，超過了10秒鐘。

在尋找根本原因的同時，我們讓Plumbr從此類有問題的節(jié)點公開了堆快照，確認長時間的GC暫停后大約70％的已用堆已被查找表完全消耗了。

同樣明顯的是，該問題還需要考慮另一個方面。 我們的存儲層基于節(jié)點集群，集群中為查詢提供服務(wù)的每臺計算機都運行多個JVM進程，而每個進程都需要相同的參考數(shù)據(jù)。

現(xiàn)在，考慮到所討論的JVM具有16G堆并有效地復(fù)制了整個查找映射，因此這也已成為容量規(guī)劃中的一個問題。 支持越來越大的堆所需的實例大小開始在我們的EC2賬單中付出了代價。

因此，我們不得不提出一種不同的解決方案，既減輕了垃圾收集的負擔(dān)，又找到了一種降低Amazon AWS成本的方法。

解決方案：編年史地圖

我們實施的解決方案基于Chronicle Map構(gòu)建。 編年史地圖在內(nèi)存鍵值存儲區(qū)中處于堆外狀態(tài)。 正如我們的測試所示，存儲的延遲時間也非常長。 但是，我們選擇Chronicle Map的主要優(yōu)勢在于它能夠跨多個流程共享數(shù)據(jù)。 因此，除了將查找值加載到每個JVM堆之外，我們只能使用集群中不同節(jié)點訪問的映射的一個副本：

在進入細節(jié)之前，讓我為您提供編年史地圖功能的高級概述，我們發(fā)現(xiàn)它特別有用。 在編年史地圖中，數(shù)據(jù)可以保存到文件系統(tǒng)中，然后由任何并發(fā)進程以“查看”模式訪問。

因此，我們的目標是創(chuàng)建一個具有“編寫者”角色的微服務(wù)，這意味著它將將所有必需的數(shù)據(jù)實時持久地保存到文件系統(tǒng)中，并作為“讀取器”的角色（即我們的Druid數(shù)據(jù)存儲）。 由于Druid不支持現(xiàn)成的Chronicle Map，因此我們實現(xiàn)了自己的Druid擴展 ，該擴展能夠讀取已經(jīng)持久保存的Chronicle數(shù)據(jù)文件，并在查詢期間以人類可讀的名稱替換標識符。 以下代碼提供了一個有關(guān)如何初始化編年史地圖的示例：

ChronicleMap.of(String.class, String.class) .averageValueSize(lookup.averageValueSize) .averageKeySize(lookup.averageKeySize) .entries(entrySize) .createOrRecoverPersistedTo(chronicleDataFile);

在初始化階段需要此配置，以確保Chronicle Map根據(jù)您預(yù)測的限制分配虛擬內(nèi)存。 虛擬內(nèi)存預(yù)分配不是唯一的優(yōu)化，如果像我們一樣將數(shù)據(jù)持久化到文件系統(tǒng)中，您會注意到創(chuàng)建的Chronicle數(shù)據(jù)文件實際上是稀疏文件 。 但這將是一個完全不同的帖子的故事，因此我不會深入探討這些。

在配置中，您需要為嘗試創(chuàng)建的編年史地圖指定鍵和值類型。 在我們的例子中，所有參考數(shù)據(jù)都是文本格式，因此我們?yōu)殒I和值都指定了String類型。

在指定鍵和值的類型之后，Chronicle Map初始化還有更多有趣的部分是獨特的。 正如方法名稱所暗示的， averageValueSize和averageKeySize都要求程序員指定期望存儲在Chronicle Map實例中的平均鍵和值大小。

通過方法條目，您可以為Chronicle Map提供可以存儲在實例中的預(yù)期數(shù)據(jù)總數(shù)。 也許有人會懷疑，如果隨著時間的推移，記錄數(shù)量超過預(yù)定義的大小會發(fā)生什么？ 顯然，如果超過了配置的限制，則在最后輸入的查詢上可能會遇到性能下降。

當超出預(yù)定義的條目大小時，還要考慮的另一件事是，如果不更新條目大小，則無法從Chronicle Map文件中恢復(fù)數(shù)據(jù)。 由于Chronicle Map在初始化期間會預(yù)先計算數(shù)據(jù)文件所需的內(nèi)存，因此，如果條目大小保持不變，并且實際上文件中包含的內(nèi)容（比如說多4倍的條目），則數(shù)據(jù)將無法容納到預(yù)計算的內(nèi)存中，因此Chronicle Map初始化將失敗。 如果要在重啟后正常運行，請務(wù)必牢記這一點。 例如，在我們的場景中，當重新啟動持久化來自Kafka主題的數(shù)據(jù)的微服務(wù)時，在初始化Chronicle Map實例之前，它會根據(jù)Kafka主題中的消息量動態(tài)計算數(shù)量條目。 這使我們能夠在任何給定時間重新啟動微服務(wù)，并使用更新的配置恢復(fù)已持久保存的Chronicle Map文件。

帶走

使Chronicle Map實例能夠在幾微秒內(nèi)讀寫數(shù)據(jù)的不同優(yōu)化立即開始產(chǎn)生良好的效果。在發(fā)布基于Chronicle Map的數(shù)據(jù)查詢后幾天，我們已經(jīng)看到了性能改進：

此外，從每個JVM堆中刪除查找映射的冗余副本可以顯著減少存儲節(jié)點的實例大小，從而在我們的Amazon AWS賬單中產(chǎn)生明顯的凹痕。

翻譯自: https://www.javacodegeeks.com/2017/02/going-off-heap-improve-latency-reduce-aws-bill.html

aws高額賬單

總結(jié)

以上是生活随笔為你收集整理的aws高额账单_取消堆放以提高延迟并减少AWS账单的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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