内核 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 )

更多

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