優化對磁盤的大容量寫入

我有一臺運行在雙Xeon芯片的計算機上的C應用程序（VStudio 2010，win7 64bit），意思是12個物理核心和24個邏輯核心，以及192個ram。編輯：操作系統是win7（即Windows 7,64位）。優化對磁盤的大容量寫入

該應用程序有24個線程（每個線程都有自己的邏輯核心）進行計算並填充大量C結構的不同部分。當所有線程完成時（線程完全平衡以便它們同時完成），結構大約爲60千兆字節。（我對硬件設置有控制權，所以我打算使用6個運行RAID 0的2TB驅動器，這意味着寫入時的物理限制大約是平均順序寫入速度的6倍，即約2吉秒/秒）

什麼是最有效的方式將其存入磁盤？很顯然，I/O時間會縮短計算時間。從我對這個主題的研究中看來，write（）（而不是fwrite（））是一種可行的方式。但是，在設置緩衝區大小等方面，我可以在軟件方面進行哪些其他優化？mmap會更高效嗎？

來源

2011-12-09 PaeneInsula

請添加一個標籤，你想寫哪種語言，以幫助他人輕鬆找到這個問題。 – Buddha

計算需要多長時間？ –

我看到一個'mmap'標籤。這可用於您的系統嗎？ –

很難判斷你的情況最好的事情。

要做的第一個優化是預先分配文件。這樣你的文件系統不需要繼續擴展它的大小。這應該優化一些磁盤操作。但是，避免寫入實際的零到磁盤。只需設置長度。

然後您可以在mmap和寫入之間進行選擇。這也取決於您使用的操作系統。在Unix上，我會嘗試mmap和pwrite。 pwrite非常有用，因爲您的每個線程都可以在所需的文件位置寫入文件，而無需爭奪文件偏移量。

mmap可能不錯，因爲不是將副本製作成文件緩存，而是將線程直接寫入文件緩存。 60 GB可能太大以至於無法映射整個文件，因此每個線程都可能需要將自己的mmap窗口放到可移動的文件上。

在Windows中，您可能會想嘗試使用重疊的異步IO。這隻能用Win32 API調用來完成。

來源

2011-12-09 19:06:28

Windows具有與mmap（CreateFileMapping，MapViewOfFile）等效的功能，並且可能與Zan列出的相同原因相同。 –

出於同樣的原因（這是操作系統使用的）映射文件在Windows上也有很好的性能。 Plus窗口可以映射網絡驅動器上的文件。 Unix不習慣能夠通過nfs進行mmap - 是否改變了？ –

mmap（）或boost mmap幾乎總是最好的方法。操作系統比你聰明，讓它擔心要緩存什麼！

你沒有說什麼操作系統，但在Linux上的madvise，或等效的提示提示可以真正提高性能。

來源

2011-12-09 19:01:24

+1，永遠，讓別人儘可能多的細節出汗！ –

優化對磁盤的大容量寫入

回答

相關問題