内核 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 调用时引入了少量延迟。此计数器的理想变化率为零；显着的非零值可能表示性能限制。

发生这种情况的原因可能是线程池中的 nfsd 线程太少，无法满足 NFS 工作负载（工作负载受线程限制），在这种情况下，配置更多 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 )

更多

其他统计信息文件的描述应在此处。