32位應用程序內存不足

Question

我有一個內存問題。自從12年來，我們在我們的軟件（C++，32Bit）中使用自己製作的表來存儲數據。 表格存儲在磁盤上。當我們想要使用它的數據時，它們被加載到內存中並停留在那裏。有些表非常大，它們有超過2百萬行。當我們將它們加載到內存 時，它們高達400MB。由於32位和內存碎片，在其他操作沒有獲得足夠的內存之前，我們實際上可以加載最多2個這樣的表int 。

軟件安裝在3000多個客戶端上。客戶端上的操作系統是win7-win10（32Bit和64Bit）以及一些微不足道的XP和Vista系統

所以我們討論了一個很好的（快速，適應）方法來解決這個問題。這裏有一些想法：

• 切換到64位
• 從我們自己的表切換在自己的進程對於SQLite或ejdb
• 開放的每個表和與過程comunicate拿到表的數據
• 擴展我們自己的表格，可以直接從磁盤讀取

所有想法都或多或少地具有可行性和速度（實現速度和執行速度）。每個想法的優點和缺點都非常複雜，並且會超出這個範圍。

有人有另一個好主意來解決這個問題嗎？

---

[更新]

我將試圖從不同的角度解釋這一點。首先，該軟件安裝在各種不同的Windows操作系統的大量基礎上，即 。從XP到W10全部都是 種電腦。該軟件可以在單個臺式機上使用，如帶有中央LAN數據池的終端 服務器（僅文件服務器上的文件夾）。 它以特殊的方式收集文章。所以有很多關於 各種商品數據的信息以及來自不同供應商的價格信息。 因此，非常需要將這些信息隱藏/隱藏給外部人員。

當前數據庫就像字符串，雙精度數據值或長數據值的內存表。 每一行可以包含一組不同的列。但大多數表格都像 結構化的數據庫表。整個表格數據被加密並壓縮成一個塊。 一旦加載完整數據就會在內存中擴展，我們可以非常快速地訪問這些數據。 如果需要索引，我們在軟件內使用std :: map。 我們嘗試將我們當前的表數據與SQLite和EJDB進行比較。包含 約50萬簡單文章數據的文件在EJDB上的數據中佔用3.5 MB，SQLite佔用28 MB，在幾個文件中佔用100 MB（在 的幾個文件中）。 SQLite和EJDB以純字符串形式顯示數據，其中簡單的二進制部分爲 ，例如「double」。因此，使用一個好的編輯器，您可以輕鬆匹配一個物品編號，價格非常便宜。

該軟件使用大約40個DLL與幾個第三方庫的依賴關係。所以從 32轉換到64位是一個挑戰。它也不能解決我們的 客戶端安裝中32Bit終端服務器的問題。

去一個真正的數據庫（如MySQL，MongoDB等）也是一個很大的挑戰，因爲我們每個月都在計算機廣泛的基礎上每月更新我們的 數據。沒有一個互聯網連接使用 真實服務器客戶端模式。

那麼我們該怎麼辦？

使用SQLite或EJDB或其他東西，並加密我們的數據在每個領域？

對我們的數據庫進行重新編程，使其使用更小的數據塊，並在需要時加載 塊，因爲它們是嵌套的？ 只有索引在內存中。用B-Tree戰略管理磁盤數據。

時間很短。所以重新發明輪子並沒有幫助。你會怎麼做或在這樣的情況下使用 ？

Answer 1

400MB。由於32位和內存碎片，我們實際上可以裝載最多2個這樣的表

你不是任何機會「加載」這個表通過分配大塊的內存和磁盤讀取表內容到它？如果是這樣，那麼你應該切換到使用較小的內存映射塊加載表（可能每個4Mb對應於大內存頁面大小）。這樣，你應該能夠利用32位程序可用的大部分3.5 Gb地址空間。