網路文件系統在高 I/O 速度期間失敗
我是使用 NFS 滿足數據儲存需求的集群上的使用者。最近，我一直在執行一個在某些操作期間具有非常高 I/O 的管道。
我們認為導致問題的程序被命名為 Bowtie，它是生物資訊學管道中的校準器。簡而言之，我們在每個文件 100 萬行的碎片文件中都有字母序列，這些文件與包含整個字典的另一個文件進行比較。（這是算法的過度簡化）
這個字典在過程中被記憶體映射。我擁有集群上三個節點的隊列送出權限。
節點： Node1 Node2 Node3 Node4 Node5 Node6 Node7
我的權利：Node1 Node2 Node3
我可用的處理器數量：128 個處理器或 128 個執行隊列槽。
為了在集群上執行，主文件被分成 100 萬行的 Chunk，然後所有的作業都使用 SGE 啟動。
此時的字典在記憶體中載入到每個節點上，即 Node1 2 和 3
對於隊列槽上的每個活動作業，我打開了以下文件處理程序
1 個包含執行程式碼的作業文件 1 個包含程序退出程式碼的程式碼文件 1 SGE 生成的 STDOUT 文件 1 SGE 生成的 STDERR 文件 1 文件塊 1 輸出文件
這意味著在此過程中，我在遠端數據儲存上打開了 768+3 個文件處理程序，儘管前四個文件對於管道中的每個腳本都是不變的。
每當發生這種情況時，數據儲存上的 NFS 伺服器就會崩潰，並且我們的整個集群都會因為儲存變得無響應而停機。
我們的 IT 人員表示，這可能是由於此過程中的高 I/O 造成的，並且 NFS 可能僅適用於小型集群而不是大型集群。
因此，我們已經解決了這個問題，我們計劃在其中一個節點本身上執行這個過程。但是，擁有一個可供我們使用的集群的意義就被否定了，因為我們將寫入節點的磁碟，而不是所有集群共享的數據儲存。
我不相信 NFS 是為小型集群建構的，並且從未在大型企業級解決方案上成功實施。NFS 突然斷開網路連接可能還有其他原因嗎？
我確信這個過程是問題是集群凍結的原因，但我不相信它要求的讀/寫速度是失敗的原因。你們之前有沒有遇到過這樣的問題？完整的協議遷移是我們唯一的解決方案嗎？
多年來學到的一些建議。
- 最小化 NFS 伺服器上的負載：
設置 NFS 導出選項：
async,insecure,no_subtree_check設置 NFS 掛載選項
soft,noatime,nodiratime,nolock,vers=3還設置：
noatime,nodiratime在 data/tmp/scratch mounts 上。確保 NFS 加密已關閉以減少負載。停止 NFS 鎖定程序。
- 嘗試在所有主機上為網路啟用 JUMBO 幀（如果網路設備支持） - 將 MTU 設置為 9k 左右。
- 確保使用 raid10 儲存（不惜一切代價避免使用 raid5/6）進行隨機寫入 IO。有SSD嗎？
- 最大化打開的 FS 句柄數（在某些系統上預設為 2K），將其設置為 1M 左右。
- 是否有機會將帶有輸入數據的映射數據庫複製到本地暫存節點儲存，而不是將生成的 sam 文件組合/排序作為單獨的步驟？
- 增加已處理塊的大小（使其處理至少 30 分鐘或更長時間。
- 如果可能，盡可能在最高級別拆分作業（嘗試在 10 個不同節點上並行映射/排序 10 個單獨的基因組/樣本，而不是嘗試使用 10 個主機串聯映射每個基因組）。在所有程序完成後嘗試檢查點。
- 修改程序源，使其以更大的塊讀取數據——比如 1M 而不是 4k。
- 請注意 CPU/RAM 互連爭用（尤其是在 AMD 4-8 插槽系統上），有時在 48 核盒上執行 12-24 執行緒比 48 執行緒快得多。嘗試不同的使用率水平。確保 NUMA 已開啟並針對多 CPU 系統進行了配置。在啟用 NUMA 的情況下重新編譯。
PS：管理一個高效的集群類似於規劃/管理一個有 1k+ 工人的建築工地……