spark減少內(nèi)存消耗

這將是另一個故事，與我們分享有關(guān)內(nèi)存相關(guān)問題的最新經(jīng)驗。 該案例是從最近的客戶支持案例中提取的，在該案例中，我們遇到了一個行為異常嚴(yán)重的應(yīng)用程序，該應(yīng)用程序因生產(chǎn)中的OutOfMemoryError消息而死。 在連接了Plumbr的情況下運行應(yīng)用程序后，我們確定這次不會遇到內(nèi)存泄漏。 但是有些事情還是非常錯誤的。

這些癥狀是通過監(jiān)控某些數(shù)據(jù)結(jié)構(gòu)的開銷的一項實驗功能發(fā)現(xiàn)的。 它給了我們一個信號，指出了源代碼中的一個特定位置。 為了保護(hù)客戶的隱私，我們使用合成樣本重新制作了案件，同時在技術(shù)上使其與原始問題相同。 隨時下載源代碼 。

我們發(fā)現(xiàn)自己盯著從外部源加載的一組對象。 與外部系統(tǒng)的通信是通過XML接口實現(xiàn)的。 這本身還不錯。 但是，集成實現(xiàn)細(xì)節(jié)分散在整個系統(tǒng)中（將收到的文檔轉(zhuǎn)換為XMLBean實例，然后在整個系統(tǒng)中使用）的事實可能并不是最明智的選擇。

本質(zhì)上，我們正在處理延遲加載的緩存解決方案。 緩存的對象是人物：

// Imports and methods removed to improve readability public class Person { private String id; private Date dateOfBirth; private String forename; private String surname; }

不太可能消耗內(nèi)存。 但是，當(dāng)我們打開一些更多的細(xì)節(jié)時，情況看起來會變得有些酸。 也就是說，該數(shù)據(jù)的實現(xiàn)類似于上面的簡單類聲明。 相反，該實現(xiàn)使用了模型生成的數(shù)據(jù)結(jié)構(gòu)。 使用的模型類似于以下簡化的XSD代碼段：

<xs:schema targetNamespace="http://plumbr.eu" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> <xs:element name="person"> <xs:complexType> <xs:sequence> <xs:element name="id" type="xs:string"/> <xs:element name="dateOfBirth" type="xs:dateTime"/> <xs:element name="forename" type="xs:string"/> <xs:element name="surname" type="xs:string"/> </xs:sequence> </xs:complexType> </xs:element> </xs:schema>

開發(fā)人員使用XMLBeans生成了在后臺使用的模型。 現(xiàn)在讓我們添加一個事實，即緩存應(yīng)該容納多達(dá)130萬個Persons實例，并且我們?yōu)槭?chuàng)建了堅實的基礎(chǔ)。

運行捆綁的測試用例表明，基于XMLBean的解決方案的130萬個實例將消耗大約1.5 GB的堆。 我們認(rèn)為我們可以做得更好。

第一個解決方案是顯而易見的。 集成細(xì)節(jié)不應(yīng)跨越系統(tǒng)邊界。 因此，我們將緩存解決方案更改為簡單的java.util.HashMap <Long，Person>解決方案。 ID為鍵，Person對象為值。 立刻我們發(fā)現(xiàn)內(nèi)存消耗減少到214MB 。 但是我們還不滿意。

由于Map中的鍵本質(zhì)上是數(shù)字，因此我們有所有理由使用Trove Collections來進(jìn)一步減少開銷。 實現(xiàn)中的快速更改，我們已經(jīng)用TLongObjectHashMap <Person>替換了HashMap 。 堆消耗降至143MB 。

我們當(dāng)然可以在這里停下來，但是出于工程方面的好奇心，我們不允許這樣做。 我們不禁注意到所使用的數(shù)據(jù)包含冗余信息。 出生日期實際上是在ID中編碼的，因此我們可以輕松地從給定的ID計算生日，而不是將其復(fù)制到其他字段中。

因此，我們更改了Person對象的布局，現(xiàn)在它僅包含以下字段：

// Imports and methods removed to improve readability public class Person { private long id; private String forename; private String surname; }

重新運行測試證實了我們的期望。 堆消耗降至93MB 。 但是我們?nèi)匀徊粷M意。

該應(yīng)用程序在具有舊JDK6版本的64位計算機(jī)上運行。 默認(rèn)情況下不壓縮普通對象指針。 切換到-XX：+ UseCompressedOops給了我們額外的勝利-現(xiàn)在我們的內(nèi)存已減少到73MB 。

我們可以走得更遠(yuǎn)，開始實習(xí)字符串或基于鍵構(gòu)建b樹，但這已經(jīng)開始影響代碼的可讀性，因此我們決定在這里停止。 21.5倍的堆減少應(yīng)該已經(jīng)足夠好了。

得到教訓(xùn)？

• 不要讓集成細(xì)節(jié)跨越系統(tǒng)邊界
• 冗余數(shù)據(jù)將耗資巨大。 盡可能刪除冗余。
• 原始人是您的朋友。 了解您的工具并學(xué)習(xí)Trove（如果您還沒有的話）
• 注意JVM提供的優(yōu)化技術(shù)

如果您對進(jìn)行的實驗感到好奇，請隨時從此處下載使用的代碼 。 描述了用于測量的實用程序，該實用程序在此博客文章中可用。

參考： Plumbr博客博客上的JCG合作伙伴 Nikita Salnikov Tarnovski 減少了20倍的內(nèi)存消耗 。

翻譯自: https://www.javacodegeeks.com/2013/06/reducing-memory-consumption-by-20x.html

spark減少內(nèi)存消耗

總結(jié)

以上是生活随笔為你收集整理的spark减少内存消耗_将内存消耗减少20倍的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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