核心 NFS 伺服器統計

作者:

Greg Banks <gnb@sgi.com> - 2009 年 3 月 26 日

本文件描述了核心 NFS 伺服器向用戶空間提供的統計資料的格式和語義。這些統計資料以多種文字形式的偽檔案提供，每個檔案在下文分別描述。

在大多數情況下，您不需要了解這些格式，因為 nfs-utils 發行版中的 nfsstat(8) 程式提供了一個有用的命令列介面來提取和列印它們。

此處描述的所有檔案都格式化為一系列文字行，由換行符“n”分隔。以井號“#”字元開頭的行是供人閱讀的註釋，解析程式應忽略它們。所有其他行都包含一系列由空格分隔的欄位。

/proc/fs/nfsd/pool_stats

如果 /proc/fs/nfsd 檔案系統已掛載（通常總是如此），則此檔案在 2.6.30 及更高版本的核心中可用。

第一行是註釋，描述了所有其他行中存在的欄位。其他行以一系列無符號十進位制數字欄位的形式呈現以下資料。每個 NFS 執行緒池顯示一行。

所有計數器均為 64 位寬，並自然迴繞。無法將這些計數器清零，應用程式應自行進行速率轉換。

pool

此行適用的 NFS 執行緒池的 ID 號。此數字不變。

執行緒池 ID 是從零開始的一組連續小整數。最大值取決於執行緒池模式，但目前不能大於系統中的 CPU 數量。請注意，在預設情況下，將只有一個執行緒池包含系統中的所有 nfsd 執行緒和所有 CPU，因此此檔案將只有一行，其池 ID 為“0”。

packets-arrived

統計已到達的 NFS 包數量。更準確地說，這是網路堆疊通知 sunrpc 伺服器層有新資料可能在傳輸（例如 NFS 或 UDP 套接字或 NFS/RDMA 端點）上可用的次數。

根據 NFS 工作負載模式和各種網路堆疊效應（例如大型接收解除安裝，它可以合併線上的資料包），此值可能多於或少於接收到的 NFS 呼叫數（該統計資料在其他地方可用）。然而，這是衡量由於 NFS 網路流量導致 sunrpc 伺服器層承受的 CPU 負載的更準確且較少依賴於工作負載的度量。

sockets-enqueued

統計 NFS 傳輸被排隊等待 nfsd 執行緒服務（即沒有 nfsd 執行緒被認為是可用的）的次數。

此統計資料跟蹤的情況表明存在需要處理的 NFS 網路面向工作，但它無法立即完成，從而在服務 NFS 呼叫時引入了小的延遲。此計數器的理想變化率為零；顯著非零值可能表示效能限制。

這可能發生是因為執行緒池中用於 NFS 工作負載的 nfsd 執行緒太少（工作負載受執行緒限制），在這種情況下，配置更多的 nfsd 執行緒可能會提高 NFS 工作負載的效能。

threads-woken

統計空閒 nfsd 執行緒被喚醒以嘗試從 NFS 傳輸接收資料的次數。

此統計資料跟蹤了傳入的網路面向 NFS 工作被快速處理的情況，這是一件好事。此計數器的理想變化率將接近但小於 packets-arrived 計數器的變化率。

threads-timedout

統計 nfsd 執行緒觸發空閒超時（即在一段時間內未被喚醒以處理任何傳入網路資料包）的次數。

此統計資料記錄了一種情況，即配置的 nfsd 執行緒數多於 NFS 工作負載可使用的數量。這暗示著可以在不影響效能的情況下減少 nfsd 執行緒數。不幸的是，這只是一個線索而不是一個強烈的跡象，原因有以下幾點：

• 目前，計數器遞增的速率非常慢；空閒超時時間為 60 分鐘。除非 NFS 工作負載連續數小時保持不變，否則此計數器不太可能提供仍然有用的資訊。

• 通常，明智的策略是提供一些餘量，即配置比當前需要多一些的 nfsd 執行緒，以應對未來負載的峰值。

請注意，NFS 傳輸上的傳入資料包將以以下三種方式之一處理：一個 nfsd 執行緒可以被喚醒（threads-woken 統計此情況），或者傳輸可以被排隊等待稍後處理（sockets-enqueued 統計此情況），或者資料包可以暫時延遲，因為傳輸當前正在被一個 nfsd 執行緒使用。最後一種情況不是很有趣，也沒有明確計數，但可以從其他計數器推斷出來，如下：

packets-deferred = packets-arrived - ( sockets-enqueued + threads-woken )

更多

其他統計檔案的描述應在此處。