fsync效能問題

2021-09-20 14:01:45 字數 658 閱讀 5831

最近在測試種發現程式裡呼叫fsync刷檔案到磁碟時,開銷只有幾百微秒,於是對fsync相關機制進行了一番調查。

磁碟(或raid卡)自身通常會有硬體快取機制,對於寫操作,有write back和write through兩種機制,前者將資料寫至快取就會返回,而後者則會將資料寫到磁碟介質上。當使用write back機制時,fsync刷的檔案資料可能只是寫到磁碟快取就返回了,導致從應用看來,寫資料到磁碟的開銷很小(實際上並未執行磁碟寫操作);所以,使用write back機制時,即使上層應用顯式fsync成功,資料也是可能丟失的,比如快取裡的資料還未刷到磁碟時掉電了,有些儲存裝置會使用備用電池(bbu,battery backup unit)來避免掉電時快取資料丟失。

如果要保證fsync呼叫成功後,資料一定持久化到磁碟,則要使用核心的write barrier機制。該機制通過在io操作之前和之後顯式重新整理儲存裝置的快取來達到目的,在檔案系統mount的時候可以指定是否開啟barrier機制,ext4預設啟用barrier機制。

對於記憶體對映(mmap)的檔案資料,msync的功能與fsync類似,將記憶體對映資料刷到磁碟,msync使用時有3個標誌。

要想對映記憶體msync後被持久化到磁碟,需要使用ms_sync標記;而msync呼叫後資料是否一定持久化,則要看儲存裝置使用的快取機制以及核心write barrier是否啟用。

關於fsync的問題及學習

1.問題 因為需要寫乙個非常重要的檔案,需要避免因系統突然斷電造成的檔案內容丟失問題的發生。而在呼叫了fopen fwrite以及sync之後,會導致系統執行過程中使用者操作卡一下。原因是sync會將buffer中所有已修改資料寫入磁碟中,如果資料量大比如會影響到系統效能。所以考慮使用fsync來s...

mysql fsync 深入理解Fsync

1 介紹 資料庫系統從誕生那天開始,就面對乙個很棘手的問題,fsync的效能問題。組提交 group commit 就是為了解決fsync的問題。最近,遇到乙個業務反映mysql建立分割槽表很慢,仔細分析了一下,發現innodb在建立表的時候有很多fsync 每個檔案會有4個fsync的呼叫。當然,...

fflush和fsync的聯絡和區別

傳統的u n i x實現在核心中設有緩衝儲存器,大多數磁碟i o都通過快取進行。當將資料寫 到檔案上時,通常該資料先由核心複製到快取中,如果該快取尚未寫滿,則並不將其排入輸出 佇列,而是等待其寫滿或者當核心需要重用該快取以便存放其他磁碟塊資料時,再將該快取排 入輸出佇列,然後待其到達隊首時,才進行實...