會不會出現這樣的情況：多個CPU同時讀取同一個文件，減慢每個CPU的讀取速度？
我正在執行
cat以單獨file_X與大量文件組合file_1，例如file_100000000000.由於數量眾多，我將作業分配到一個有 64 個 CPU 的節點上，以便在每個 CPU 上並行執行。每個作業都在一個子文件夾中執行，因此有 64 個子文件夾。
令我驚訝的是，整體速度比預期的要慢得多。
由於我使用的shell腳本只是將每個作業指向
file_X位於64個子文件夾的父目錄中的同一個文件，我想知道如果多個CPU同時讀取同一個文件，會減慢每個CPU的讀取速度嗎？
是和不是。
無論有多少處理器在執行此操作，文件的實際讀取都應該以相同的速度發生。
但是，根據作業系統及其配置，可能會發生文件鎖定。雖然多個程序可以同時擁有一個讀鎖，但獲取鎖和釋放該鎖必鬚髮生在共享互斥塊中。如果您的系統正在執行這些類型的鎖定，則處理器必須排隊以訪問文件，然後必須排隊以聲明他們對文件缺乏進一步的興趣。
根據儲存 file_X 的文件系統和與之組合的各種文件以及掛載該文件系統的選項，每次 cat 讀取 file_X 時，它的訪問時間可能會更新。如果是這種情況，很可能會在每次更新之前對 file_X inode 進行寫鎖定，然後將其釋放。
速度降低的另一個可能原因是所有 64 個作業都在並行寫入文件，這些文件必然位於磁碟上的不同點上。除非您使用的是固態驅動器 (SSD)，否則可能需要在磁碟上大量移動寫入頭。這些文件位於 64 個不同的目錄中，因此除了正在創建的文件之外，還有 64 個位置需要更新。
在 shell 腳本中執行所有這些活動意味著每個文件副本都是分叉執行的。Fork 被視為一個相當昂貴的系統呼叫，但在具有共享庫的系統上，與 exec 系列系統呼叫的成本相比，它相形見絀，因為這需要搜尋每個共享庫並載入所有共享庫圖書館。這是另一個可能在文件上放置讀鎖的地方，具體取決於它所在的 unix 以及它的配置可能是什麼。