許多小文件或一個大文件？ （或者開放的開銷和關閉文件句柄）

Question

我創建了執行以下操作的應用程序（C++）：

1. 做一些計算，寫計算出的數據到一個文件 - 重複50萬次（總共寫500,000個文件） - 再重複2次（總共寫1.5個密爾文件）。從文件
2. 讀數據，做一些激烈的計算從文件中的數據 - 重複了150萬次迭代（遍歷所有寫在步驟1中的文件）
3. 重複步驟2 200次迭代。

每個文件都是〜212k，所以我有大約300Gb的數據。看起來整個過程需要花費大約40天才能在2.8 Ghz的Core 2 Duo CPU上運行。

我的問題是（你可能猜到）是完成整個過程所花費的時間。所有的計算都是串行的（每次計算都依賴於之前的計算），所以我不能將這個過程並行到不同的CPU或PC。我試圖考慮如何使這個過程更有效率，我敢肯定，大部分的開銷是文件系統訪問（呃......）。每次我訪問一個文件，我打開一個句柄，然後關閉它，一旦我讀完數據。

提高運行時間的一個想法是使用一個300Gb的大文件（或每個50Gb的幾個大文件），然後我只使用一個打開的文件句柄，並簡單地查找每個相關數據並閱讀它，但我不是什麼是打開和關閉文件句柄的開銷。有人可以對此有所瞭解嗎？

我的另一個想法是嘗試將文件分組到更大的〜100Mb文件，然後每次讀取100Mb而不是多個212K讀取，但實現起來比上述想法複雜得多。

無論如何，如果任何人都可以給我一些建議或有任何想法如何提高運行時間，我將不勝感激！

謝謝。

探查更新：

我跑的過程中探查，它看起來像計算需要運行時的62％和讀取文件需要34％。這意味着，即使我奇蹟般地將文件I/O成本削減了34倍，我仍然留下了24天，這是一個相當大的改進，但仍然很長時間:)

Answer 1

打開文件句柄isn'可能成爲瓶頸;實際的磁盤IO是。如果您可以並行磁盤訪問（例如通過使用多個磁盤，更快的磁盤，RAM磁盤......），您可能會獲益更多。另外，請確保IO不會阻塞應用程序：從磁盤讀取數據，並在等待IO時進行處理。例如。帶有閱讀器和處理器線程。

另一件事：如果下一步取決於當前的計算，爲什麼要通過將其保存到磁盤的努力？也許有了另一個關於進程依賴性的觀點，你可以修改數據流並消除大量的IO。

哦，是的，和衡量IT :)

Answer 2

使用內存映射文件應進行調查，因爲它會降低系統調用的次數。

Answer 3

每個文件是〜212K，所以我有 〜300Gb的數據。它看起來像整個過程需要大約40天...一個 計算串行（每個 計算取決於之前的一個 ），所以我不能將這個 過程並行到不同的CPU或PC。 ...漂亮 肯定最大的開銷去 文件系統訪問...每當我訪問一個文件我打開一個文件 到它，然後關閉它，一旦我完成 讀取數據。

連續寫入數據300GB的數據可能需要40分鐘，僅爲40天的一小部分。磁盤寫入性能不應該成爲問題。

您只有一次打開文件的想法是點亮的。每次操作後關閉文件可能會導致您的處理阻塞，直到磁盤完全寫出所有數據，否定了磁盤緩存的好處。

我敢打賭，這個應用程序的最快實現將使用內存映射文件，所有現代操作系統都具備這種能力。它最終也可能是最簡單的代碼。您將需要一個64位處理器和操作系統，您應該而不是需要300GB的RAM。一次將整個文件映射到地址空間，只需使用指針讀取和寫入數據。

Answer 4

在進行任何更改之前，運行分析器跟蹤以瞭解大部分時間用於確保實際優化實際問題的位置可能很有用。

Answer 5

怎麼樣使用SQLite？我認爲你可以擺脫一張桌子。

Answer 6

從您的簡要說明中，聽起來像xtofl建議的線程是正確的方法。我會建議你先分析你的應用程序，但要確保時間在IO和CPU之間分配。

然後我會考慮三個線程加入兩個隊列。

1. 線程1讀取文件並將它們加載到ram中，然後將數據/指針放入隊列中。如果隊列超過一定的大小，則線程休眠，如果再次開始時線程低於特定大小。
2. 線程2讀取從隊列中的數據並執行計算，然後將數據寫入到第二隊列
3. 線程3讀取第二隊列，並將數據寫入到磁盤

你可以考慮合併線程1和3，這可能會減少磁盤上的爭用，因爲您的應用程序一次只能執行一個磁盤操作。

另外操作系統如何處理所有文件？他們都在一個目錄中嗎？當您瀏覽目錄（gui filemanager/dir/ls）時性能如何？如果這種性能很差，您可能會在文件系統舒適區之外工作。儘管你只能在unix上改變它，但有些文件系統針對不同類型的文件使用進行了優化，例如大文件，大量小文件等。您還可以考慮將文件分割到不同的目錄中。