OpenHFT ChronicleMap內存的限制和限制

Question

這篇文章可能是OpenHFT常見問題的一個很好的候選人。

我在玩ChronicleMap考慮它的想法，但有很多問題。我相信大多數正在研究此產品的初級程序員都有類似的考慮。

你能解釋一下這個API如何管理內存嗎？

ChronicleMap宣佈了一些顯着的TBs堆外存儲器資源可用於處理其數據，我想清楚的看到這一點。

讓我們來找一個帶有500GB HD和4GB RAM的筆記本電腦的程序員。在這種情況下，純數學賽車 - 可用「交換」內存的總資源爲504GB。讓我們給OS和其他程序一半，我們剩下250GB高清和2GB內存。你能否詳細說明實際可用的內存ChronicleMap可以根據可用資源分配數量？

下一個相關的問題是關於ChronicleMap的實現。

我的理解是，每個ChronicleMap都會分配它所處理的內存塊，並在我們能夠準確預測通過的數據量時實現最佳的性能/內存使用率。但是，這是一個充滿活力的世界。

讓我們設置（誇張但是可能）例如：

假設地圖一個K（密鑰）「城市」和它們的V（值） - 「描述」（城市的）和允許用戶大範圍描述長度。

第一用戶輸入：K = "Amsterdam"，V = "City of bicycles"和該條目用於聲明地圖 - 它爲所述一對這樣的先例：

ChronicleMap<Integer, PostalCodeRange> cityPostalCodes = ChronicleMap 
    .of(CharSequence.class, CharSequence.class) 
    .averageKey("Amsterdam") 
    .averageValue("City of bicycles") 
    .entries(5_000) 
    .createOrRecoverPersistedTo(citiesAndDescriptions); 

現在，下一個用戶被運走，並寫入的測定關於布拉格 他傳遞到：K = "Prague"，V = "City of 100 towers is located in the hard of Europe ... blah, blah... million words ..."

現在的程序員曾預計最大5_000條目，但它得到了他的手，並有好幾千個條目。

ChronicleMap會自動爲這種情況分配內存嗎？如果是，是否有更好的方法來爲這個動態解決方案聲明ChronicleMaps？如果不是，你會推薦一種方法（最好在代碼示例中）如何最好地處理這種情況？

這是如何與持久性文件工作？

Can ChronicleMaps會耗盡我的RAM和/或磁盤空間嗎？避免這種情況的最佳做法？

換句話說，請解釋如何在低估和高估值（和/或密鑰）長度和條目數量的情況下管理內存。

以下哪些適用於ChronicleMap？

1. 如果我分配大塊（.entries(1_000_000)，.averageValueSize(1_000_000)和實際使用情況是 - 項= 100，和平均值大小= 100。

，會發生什麼？：

1.1。 - 一切正常，但會有大量浪費的塊 - 未使用？

1.2。 - 一切工作正常，未使用的內存可用於：

1.2.1 - ChronicleMap

1.2.2 - 給出了使用ChronicleMap

1.2.3線程 - 給定的過程

1.2.4 - 給定JVM

1.2.5 - 操作系統

1.3。 - 請解釋一下未使用的內存是否會發生其他問題

1.4。 - 超大小的聲明對我的持久性文件做了什麼？

相反的情況下的1 - I分配小塊（.entries(10)，.averageValueSize(10)和實際使用是條目1_000_000s，和平均值大小=字節1_000s 會發生什麼情況？：

。

Answer 1

讓我們坐下來與500GB HD和4GB內存的筆記本電腦程序員在這種情況下，純數學賽斯 - 。可用的「交換」內存資源總量爲504GB讓我們給操作系統和其他軟件半我們只剩下250GB的HD和2GB的內存，您能詳細說明一下實際可用的內存嗎ChronicleMap可以根據可用的資源分配數量urces？

在這樣的條件下，Chronicle Map將非常緩慢，平均每次使用Chronicle Map進行2次隨機磁盤讀寫操作（總共4次隨機磁盤操作）。傳統的基於磁盤的數據庫引擎（如RocksDB或LevelDB）在數據庫大小比內存大得多時應該更好。

---

現在的程序員曾預計最大5_000條目，但它得到了他的手，並有好幾千個條目。

ChronicleMap會自動爲這種情況分配內存嗎？如果是，是否有更好的方法來爲這個動態解決方案聲明ChronicleMaps？如果不是，你會推薦一種方法（最好在代碼示例中）如何最好地處理這種情況？直到通過ChronicleMappBuilder.entries()配置的數量除以插入項的實際數目是不大於配置ChronicleMapBuilder.maxBloatFactor()更高

紀事地圖將分配內存。例如，如果你創建一個地圖作爲

ChronicleMap<Integer, PostalCodeRange> cityPostalCodes = ChronicleMap 
    .of(CharSequence.class, CharSequence.class) 
    .averageKey("Amsterdam") 
    .averageValue("City of bicycles") 
    .entries(5_000) 
    .maxBloatFactor(5.0) 
    .createOrRecoverPersistedTo(citiesAndDescriptions); 

它會開始嘗試插入新的條目，當規模將是25〜000投擲IllegalStateException。

然而，紀事地圖作品越來越慢，當實際規模的增長遠遠超出了配置的大小，所以最大可能maxBloatFactor()被人爲限制在1000

的解決方案，現在是配置紀事未來的規模至少近似正確地通過entries()（和averageKey()和averageValue()）映射。

預先配置合理的Chronicle Map大小的要求被認爲是一個可用性問題。 There is a way to fix this and it's on the project roadmap.

---

換句話說，請解釋存儲器是如何在的情況下，管理低估和過度估計的值（和/或鍵）的長度和條目數的。

鍵/值大小欠估計：空間被浪費在hash lookup area，〜8個字節*低估因子，每個條目。所以如果實際的平均條目尺寸（鍵+值）很小，那麼它可能是非常糟糕的，例如， G。 50個字節，並且已將其配置爲20個字節，則會浪費〜8 * 50/20 = 20個字節或40％。平均入場人數越多，浪費越小。

鍵/值大小高估：如果你只配置鍵和值平均規模，但不actualChunkSize()直接，實際塊大小自動1/8平均條目大小的1/4之間選擇（鍵+值）。實際的塊大小是Chronicle Map中的分配單位。因此，如果將平均條目大小配置爲〜1000字節，則實際的塊大小將選擇在125到250個字節之間。如果實際平均條目大小僅爲100字節，則會損失大量空間。如果過高估計很小，預期的空間損失將限制在數據大小的20％左右。

因此，如果您擔心可能會高估平均鍵/值大小，請明確配置actualChunkSize()。

上面討論的條目數低估：。沒有特別的空間浪費，但是Chronicle Map運行速度越慢，低估越嚴重。

條目數過高估計：在散列查找區中浪費了內存，每條記錄約8字節*高估因子。根據實際的平均條目數據大小，請參見上面的關鍵/值大小低估部分可能會有多好或多壞。