Cache
將文件載入到記憶體後的文件訪問時間
我從這裡讀到我可以使用以下命令將文件載入到 RAM 中以便更快地訪問。
cat filename > /dev/null
但是,我想測試一下上述說法是否屬實。所以,我做了下面的測試。
- 創建一個 2.5 GB 的測試文件,如下所示。
dd if=/dev/zero of=demo.txt bs=100M count=10
- 現在,計算文件訪問時間如下。
mytime="$(time ( cat demo.txt ) 2>&1 1>/dev/null )" echo $mytime real 0m19.191s user 0m0.007s sys 0m1.295s
- 按照命令的建議,現在我需要將文件添加到記憶體中。所以我做了,
cat demo.txt > /dev/null
- 現在,我假設文件已載入到記憶體中。所以我計算了再次載入文件的時間。這是我得到的價值。
mytime="$(time ( cat demo.txt ) 2>&1 1>/dev/null )" echo $mytime real 0m18.701s user 0m0.010s sys 0m1.275s
- 我重複了步驟 4 5 次以上的迭代來計算時間,這些是我得到的值。
real 0m18.574s user 0m0.007s sys 0m1.279s real 0m18.584s user 0m0.012s sys 0m1.267s real 0m19.017s user 0m0.009s sys 0m1.268s real 0m18.533s user 0m0.012s sys 0m1.263s real 0m18.757s user 0m0.005s sys 0m1.274s
所以我的問題是,為什麼即使文件載入到記憶體中時間也會變化?我期待,因為文件被載入到記憶體中,每次迭代的時間應該會下降,但似乎並非如此。
不不不!
這不是它的完成方式。Linux(核心)可以選擇將一些文件放入記憶體中,並在需要時刪除它們。您真的無法確定記憶體中是否存在任何內容。這個命令不會改變(很多)。
您提供的連結中的建議在很多方面都是錯誤的!
- 記憶體是作業系統的東西。您無需
cat
文件即可/dev/null
利用此功能。這實際上是一件非常愚蠢的事情,因為你強迫 Linux 多讀一次文件。例如,如果您計劃讀取一個文件 4 次。如果你不關心它,第一次閱讀會很慢,後面的3次應該會更快(因為記憶體)。如果你使用這個“技巧”,第一次閱讀會很慢,所有後續的4個應該更快(但不是 null)。讓 Linux 處理它。- 此命令僅在您想確保 Linux 將其保存在 RAM 中時才有用。因此,您必須在系統空閒時經常執行它。然而,正如我所說,這也是愚蠢的,因為你永遠無法確定 Linux 是否真的將文件記憶體在 RAM 中,即使它確實記憶體了,你也會花時間在 RAM 或磁碟上讀取它(如果它沒有被記憶體或已經從記憶體中刪除)。
- 通過在一個大文件上重複執行此操作,您基本上可以欺騙 Linux 認為該文件應該位於 RAM 中,而犧牲了您實際更經常使用的其他文件。
所以這裡的結論是:不要做這種花招,這通常會適得其反。
但是,如果您知道某些小文件(與您的 RAM 大小相比)會真正受益於從 RAM 訪問,您可以使用
tmpfs
掛載並將文件儲存在那裡。在現代發行版中,該/tmp
文件夾通常是tmpfs
一個。我個人認為值得的另一種選擇是使用 BTRFS 在 FS 級別壓縮您的文件,例如或手動(但這個要求訪問文件的程序能夠解壓縮它)。當然,您的文件應該受益於壓縮,否則這是無用的。這樣,您可以更加確信 Linux 將壓縮文件保存在 RAM 中(因為它更小),並且如果您的應用程序受 IO 限制,從磁碟載入 100MB 而不是載入 10GB 應該會快得多。