当我们用更多的请求加载服务器时,cpu wait和irq正在增加。 内存不是问题。
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。
iostat的NFS挂载:
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
嘿,呃? 但是没有setattr和/ proc / self / mountstats:
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
nodiratime也可能有所帮助,但是,我认为这是在setattr报道
cpu0具有非常高的硬件/软件中断,即使考虑到你的数据集大多是冷的,cpu1也有200mb / sec的相当高的等待时间。 如果这些video很长,那么如果eth1的mtu很小,那么你的rsize可能会导致过度的碎片化。 我几乎认为你的rsize太高了。 您可以使用dd和各种挂载选项从另一个工作站运行一些testing,以查看32768是否会对事物产生负面影响。
和Isilon签一张票,他们的技术人员也很擅长debugging。