☰

為什麼檔案系統密集型腳本在 RAM 磁碟上速度不快

tag-icon • tag-icon performance ramdisk
為什麼檔案系統密集型腳本在 RAM 磁碟上速度不快

我有一個創建很多文件和目錄的腳本。該腳本對處理大量文件和目錄的程式進行黑盒測試。測試計數增加且測試時間過長（超過 2 秒）。我以為我在內存盤中運行測試。

我在 中運行了測試/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 核心處理檔案系統快取的效率如此之高，以至於它實際上是一個記憶體支援的檔案系統嗎？

答案1

一般來說，所有操作首先發生在 RAM 中—檔案系統被快取。這個規則也有例外，但這些相當特殊的情況通常源自於非常特定的要求。因此，在您開始進行快取刷新之前，您將無法辨別其中的差異。

另一件事是，性能取決於很多在確切的文件系統上- 有些目標是更輕鬆地訪問大量小文件，有些目標是高效地與大文件進行實時數據傳輸（多媒體捕獲/流媒體），有些強調數據一致性，而另一些則可以設計為具有記憶體/程式碼佔用空間小。

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

答案2

比我對主要由小交易組成的測試的評論的回應要長一些。

工作量不足以測試

如果您想對檔案系統進行壓力測試，您將需要更大的工作集。

根據您的盒子上有多少內存，即使是數十或數千個資料夾建立操作也不會顯示兩者之間的明顯差異。因此，修改您的工作負載以充分測試檔案系統，同時考慮將用作緩衝區的記憶體。

有多種方法可以設計測試來抵消系統記憶體和其他會影響測試結果的因素的優勢。

或者，您可以使用標準化測試套件，例如 bonnie++

相關內容