此問題是我之前發佈的一個問題的後續操作：Windows fsync (FlushFileBuffers) performance with large files。我在哪裏找到了可能的解決方案，但也有新的問題說明/尋求信息：Windows使用「fsync」（FlushFileBuffers）寫入I/O性能
雖然對不同的情景進行基準測試，但我發現了一些令人驚訝的結果。我希望有人能夠幫助解釋或指出解釋這些結果的信息方向。
這個基準測試所做的是將8個頁面（32 K）的隨機塊（頁面大小爲4096個字節）按順序寫入文件，然後刷新寫入。它共寫了200000頁，共計800 MB和25000次沖洗。在開始寫入之前，文件的大小設置爲最終長度。寫間歇或正常沖洗（NS）後
- 要執行「的fsync」/
FlushFileBuffers操作（FS）：它支持總共4個選項，其中的所有組合中運行。
- 在開始寫入（LB）或將文件保留爲空（E）之前，將單個字節寫入文件的最後位置。
- 使用正常緩衝寫入（B）或未緩衝/寫入（WT）寫入（使用FILE_FLAG_NO_BUFFERING和FILE_FLAG_WRITE_THROUGH）。
- 要直接寫入文件流，即通過文件句柄（F）或使用內存映射（MM）間接寫入文件。
下表總結了我的系統（64位Win 7筆記本電腦，主軸緩慢）的這些選項的結果。
我發現那是什麼「fsynced」緩衝寫入的性能與文件大小呈指數下降到使大文件這樣做不可行結合一個令人難以置信的低產量。如果文件的最後一個字節被寫入（選項LB），吞吐量甚至更低，所以我擔心隨機而不是順序寫入的情況下，性能會更加劇烈。
然而令人驚訝的是，對於無緩衝/寫入I/O，吞吐量保持不變，與文件大小無關。最初（第一個100-200 MB）它的吞吐量低於緩衝寫入的吞吐量，但之後平均吞吐量迅速增加，並且完成寫入800 MB的速度更快。更令人驚訝的是，如果文件的最後一個字節被寫入，吞吐量將增加2倍。
通過內存映射文件寫入文件時，可以看到同樣的性能指數下降，在使用無緩衝/寫入標誌打開文件的情況。而且在這裏，如果文件有一個字節寫入其最後位置，則性能會變差。
UPDATE 基於霍華德的解釋here和here，我重新測試，而無需啓動之前寫創建一個新的文件（即打開現有的，充分的書面文件，並覆蓋它）。我更新了原始問題中的代碼，以反映爲此測試所做的更改。結果與他在Linux上的解釋和發現部分一致。但是有一些明顯的例外。下表提供結果，紅色突出顯着變化，藍色突出顯示未發生變化，這是令人驚訝的。如果霍華德的解釋中提到的效應是唯一的影響，則不符合預期）。
對於緩衝寫入到文件（即，不通過MEMMAP）與「FSYNC」齊平，性能已經從指數衰減到一個恆定的趨勢變化。但是，現在比以前的測試場景需要更長的時間。吞吐量是一個恆定的1.5 MB/s，在那之前它以20 MB/s左右的速度開始以指數衰減到1.5 MB/s左右。看起來可能的解釋是，文件元數據也在每次刷新時被刷新，導致完整的磁盤革命尋找元數據的位置。
對於提交的方案「通過寫」，結果寫的最後一個字節與否，現在相同，是結合從霍華德的解釋預期線。
的寫入不過，內存映射，有一個明顯的例外，還沒有真正改變，這是令人驚訝的。它們在寫入性能上仍然表現出同樣的指數衰減（從大約20 MB/s衰減到1.8 MB/s）。這表明有不同的機制在發揮作用。一個值得注意的例外是如果底層文件是在沒有FILE_FLAG_WRITE_THROUGH的情況下創建的，並且執行了「fsync」刷新。這種情況現在顯示了一個恆定（較差）的性能，吞吐量約爲1.6 MB/s。由於我有些懷疑，我多次重複這個場景，每次都會得到相同的結果。爲了確定fsync性能（對於緩衝I/O）實際上取決於文件大小，我還使用更小的文件（50000頁，總計200 MB）重新測試了此測試。結果如下所示，值得特別注意的以紅色突出顯示。
這些結果很好的相關性與什麼被認爲對於較大的文件。值得注意的變化是對於突出顯示的內容，寫入性能稍高一些，他們似乎達到了約7 MB/s的限制。
概括爲基於觀察在我的系統正到目前爲止高度投機結論：
- 上（不FILE_FLAG_WRITE_THROUGH標誌IE）上的文件與緩衝的IO窗口「FSYNC」性能呈指數下降已經寫入文件的字節數。原因似乎是每次都需要刷新文件元數據，這會導致磁盤尋找文件的開頭。
- 寫入內存映射文件時，Windows上的「fsync」性能也顯示指數級下降的性能。我目前沒有解釋造成這種情況的確切機制。
鑑於觀察到的性能，至少在我的使用情況下，這兩個I/O選項不代表可行的解決方案。
按Greg's suggestion我將重新開始與Windows磁盤緩存測試關閉，我也將運行霍華德提供benchmark code排除結果歪斜由於我自己的錯誤的可能性。
UPDATE 2 我已完成測試，目前正在編譯結果。爲了不寫「完整的歷史」，我將用結果，發現和一些結論的摘要來替換這個問題的當前內容。霍華德在這個問題上的答案，以及在.NET代碼旁邊運行他的c基準代碼的能力最有用。這些應用程序的結果相關性很好。 Rlb的回答幫助我更好地理解與磁盤相關的「合理數字」是什麼。謝謝。
問題的一部分仍未得到答覆。特別涉及在寫入存儲器映射時觀察到的降低（和文件大小相關）性能。它可能與搜索/元數據沖洗有關，但目前還不清楚爲什麼/如何。
如果你只是你的最終時序報告收集之前關閉TMPFILE，這並不改變號碼？你的一些結果很有意思，所以也可以嘗試和重現。您運行場景的順序是否有效？ – rlb
臨時文件已關閉。該構造用於創建一個新的空文件，設置其長度並可選填充最後一個字節。之後它關閉。該文件在開始寫入之前重新打開。 – Alex
@rlb並沒有訂單沒有實際效果。由於我們每次從頭開始創建文件，並用隨機字節填充文件，因此不會發生緩存效果。運行獨立場景可以獲得幾乎相同的結果。 – Alex