為什麼文件系統密集型腳本在 ram 磁碟上不更快

我有一個創建大量文件和目錄的腳本。該腳本對處理大量文件和目錄的程序進行黑盒測試。測試計數增加，測試時間過長（超過 2 秒）。我以為我在 ram 磁碟中執行測試。

我在/dev/shm. 奇怪的是，它並沒有跑得更快。平均執行時間與普通硬碟上的大致相同。我還嘗試了用 perl 編寫的基於熔斷器的 ram 磁碟。該網站已消失，但我在網際網路檔案中找到了它。保險絲 ram 磁碟上的平均執行時間甚至更慢。也許是因為 perl 程式碼的次優實現。

這是我的腳本的簡化版本：

#! /bin/sh

preparedir() {
 mkdir foo
 mkdir bar
 touch bar/file
 mkdir bar/baz
 echo qux > bar/baz/file
}

systemundertest() {
 # here is the black box program that i am testing
 # i do not know what it does exactly
 # but it must be reading the files
 # since it behaves differently based on them
 find $1 -type f -execdir cat '{}' \; > /dev/null

singletest() {
 mkdir actual
 (cd actual; preparedir)
 systemundertest actual
 mkdir expected
 (cd expected; preparedir)
 diff -qr actual expected
}

manytests() {
 while read dirname; do
   rm -rf $dirname
   mkdir $dirname
   (cd $dirname; singletest)
 done
}

seq 100 | manytests

真正的腳本會做更多的錯誤檢查和結果收集和總結。這find是我正在測試的實際程序的虛擬程序。

我想知道為什麼我的文件系統密集型腳本不能在記憶體支持的文件系統上執行得更快。是因為 linux 核心如此有效地處理文件系統記憶體，以至於它實際上是一個記憶體支持的文件系統嗎？

一般而言，所有操作都首先發生在 RAM 中——文件系統被記憶體。這條規則也有例外，但這些相當特殊的情況通常來自非常具體的要求。因此，在您開始刷新記憶體之前，您將無法區分。

另一件事是，性能在很大程度上取決於確切的文件系統 - 有些目標是更容易訪問大量小文件，有些在大文件（多媒體擷取/流媒體）之間的實時數據傳輸方面效率很高，有些強調數據的一致性，其他的可以設計成具有較小的記憶體/程式碼佔用。

回到你的案例：在一個循環中，你產生了大約 20 個新程序，其中大部分只創建一個目錄/文件（注意，()創建一個子 shell 並為每個匹配項find產生）——瓶頸確實不是cat文件系統（如果您的系統使用ASLR並且您沒有良好的快速熵源，那麼您系統的隨機池也會很快耗盡）。用 Perl 編寫的 FUSE 也是如此——它不是適合這項工作的工具。

引用自：https://unix.stackexchange.com/questions/73309