我是使用 NFS 來滿足資料儲存需求的叢集上的使用者。最近，我一直在運行一個管道，在某些操作期間 I/O 非常高。
我們認為導致該問題的程式名為 Bowtie，它是生物資訊管道中的對齊器。簡而言之，我們在每個檔案 100 萬行的碎片檔案中擁有字母序列，並將其與包含整個字典的另一個檔案進行比較。 （這是演算法的過度簡化）
該字典在過程中被映射到記憶體。我對叢集上的三個節點有隊列提交權限。
節點： 節點1 節點2 節點3 節點4 節點5 節點6 節點7
我的權利：Node1 Node2 Node3
我可用的處理器數量：128 個處理器或 128 個運行佇列槽。
為了在叢集上運行，主檔案被分成每個 100 萬行的區塊，然後所有作業都使用 SGE 啟動。
此時的字典已載入到記憶體中的每個節點上，即 Node1、2 和 3
對於佇列槽上的每個活動作業，我開啟以下文件處理程序
1 個包含執行程式碼的作業檔案 1 個包含進程退出程式碼的程式碼檔案 1 SGE 產生的 STDOUT 檔案 1 SGE 產生的 STDERR 檔案 1 檔案區塊 1 輸出文件
這意味著在此過程中，我在遠端資料儲存上開啟了 768+3 個檔案處理程序，儘管前四個檔案對於管道中的每個腳本都是不變的。
每當發生這種情況時，資料儲存上的 NFS 伺服器就會崩潰，整個叢集也會因為儲存變得無回應而宕機。
我們的 IT 人員表示，這可能是由於此過程中的高 I/O 造成的，並且 NFS 可能僅適用於小型集群，而不適用於大規模集群。
因此，我們已經解決了這個問題，我們計劃在其中一個節點本身上運行這個過程。但是，擁有一個可供我們使用的叢集的意義就被否定了，因為我們將寫入節點的磁碟，而不是跨所有叢集共享的資料儲存。
我不相信 NFS 是為小型叢集建置的，並且從未在大型企業級解決方案上成功實施過。 NFS 突然斷開網路連線是否還有其他原因？
我確信該進程有問題是叢集凍結的原因，但我不相信它所需的讀取/寫入速度是失敗的原因。你們有人以前遇到過這樣的問題嗎？完整的協定遷移是我們唯一的解決方案嗎？
答案1
多年來學到的一些建議。
- 最小化 NFS 伺服器上的負載：
設定 NFS 導出選項：async,insecure,no_subtree_check
設定 NFS 掛載選項soft,noatime,nodiratime,nolock,vers=3
也設定：noatime,nodiratime在 data/tmp/scratch 安裝上。確保 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：管理一個高效的集群類似於規劃/管理一個擁有超過 1000 名工人的建築工地...