☰

分析已加载的 NFS lighttpd 服务器

tag-icon • tag-icon linux nfs lighttpd
分析已加载的 NFS lighttpd 服务器
  • 语境：
    • 服务器是 CentOS 5.2 x86_64 虚拟机，带有 vmxnet3 ifaces，在基于 Nehalem 的服务器上的 VSphere 4.1 上运行（根据 VCenter，该服务器的 CPU 和内存容量为一半），网络为 10 Gb。根据 iostat，虚拟机的虚拟 scsi 磁盘上的 i/o 几乎为零。
    • 使用 NFS 从 Isilon 群集读取视频（atime 已禁用）
    • 使用 lighttpd 1.5.0 为他们提供服务，其 CPU 占用率为 20%。大约有 650 个 HTTP 连接，其中 550 个已建立，Send-Q 中的平均连接数为 100 Kb。

随着我们向服务器加载更多请求，CPU 等待和中断也随之增加。内存不是问题。

Cpu0  :  0.0%us,  3.0%sy,  0.0%ni, 18.0%id,  0.0%wa, 32.0%hi, 47.0%si,  0.0%st
Cpu1  :  3.0%us,  4.0%sy,  0.0%ni, 55.4%id, 34.7%wa,  0.0%hi,  3.0%si,  0.0%st

根据 /proc/interrupts，HTTP 使用的接口上有 4163 irq/s，NFS 使用的接口上有 2269 irq/s。根据 iptraf，分别为 180 Mbps 和 130 Mbps。

NFS 挂载的 iostat：

rBlk_nor/s   wBlk_nor/s   rBlk_dir/s   wBlk_dir/s   rBlk_svr/s   wBlk_svr/s    rops/s    wops/s
63737.87         0.00         0.00         0.00     61364.71         0.00   1098.04   1107.84

嘿，你好？但是 /proc/self/mountstats 上没有 setattr 之类的东西：

    opts:   ro,vers=3,rsize=32768,wsize=32768,acregmin=1200,acregmax=1200,acdirmin=1200,acdirmax=1200,hard,intr,proto=tcp,timeo=600,retrans=2,sec=sys
    age:    2405948
    caps:   caps=0x1,wtmult=8192,dtsize=4096,bsize=0,namelen=255
    sec:    flavor=1,pseudoflavor=1
    events: 3496282 32148506 1 1697 3176945 2598729 37924190 0 33339443 67286271 0 0 20 0 0 0 0 3176406 0 0 0 0 0 0 0
    bytes:  31773968205376 0 0 0 31969360034250 0 7805430344 0
    RPC iostats version: 1.0  p/v: 100003/3 (nfs)
    xprt:   tcp 779 0 50 250 0 1014646219 1014646203 0 8377876491 11916594888
    per-op statistics
            NULL: 0 0 0 0 0 0 0 0
         GETATTR: 3496282 3496282 0 461510280 391583584 2165765 2594488 5332330
         SETATTR: 0 0 0 0 0 0 0 0
          LOOKUP: 2598882 2598882 0 374792176 623714816 3558569 79355750 83640121
          ACCESS: 2824036 2824036 0 384066672 338884320 1788232 2276978 4482334
        READLINK: 0 0 0 0 0 0 0 0
            READ: 1005726981 1005726982 0 144824685416 32098094238420 7454826308 4671373832 13644100410
           WRITE: 0 0 0 0 0 0 0 0
          CREATE: 0 0 0 0 0 0 0 0
           MKDIR: 0 0 0 0 0 0 0 0
         SYMLINK: 0 0 0 0 0 0 0 0
           MKNOD: 0 0 0 0 0 0 0 0
          REMOVE: 0 0 0 0 0 0 0 0
           RMDIR: 0 0 0 0 0 0 0 0
          RENAME: 0 0 0 0 0 0 0 0
            LINK: 0 0 0 0 0 0 0 0
         READDIR: 0 0 0 0 0 0 0 0
     READDIRPLUS: 13 13 0 2132 23788 60 1240 1300
          FSSTAT: 2 2 0 256 336 0 0 0
          FSINFO: 1 1 0 128 164 0 10 10
        PATHCONF: 0 0 0 0 0 0 0 0
          COMMIT: 0 0 0 0 0 0 0 0
  • 如何判断 iowait 和 irq cpu 使用率的问题出在 HTTP 端还是 NFS 端？或者如何判断 VSphere 主机是否已达到其 I/O 限制？

答案1

nodiratime 可能也有帮助，但我认为 setattr 下也有报告

cpu0 具有非常高的硬件/软件中断，而 cpu1 的等待时间在 200mb/秒时相当长，即使考虑到您的数据集大部分是冷的。如果这些是长视频，如果 eth1 的 mtu 较小，您的 rsize 可能会导致过度碎片化。我几乎认为您的 rsize 太高了。您可以使用 dd 和各种挂载选项从另一个工作站运行一些测试，以查看 32768 是否对事物产生负面影响。

向 Isilon 提交一张票，他们的技术人员也非常擅长调试这个问题。

相关内容