linux – 奇怪的nfs性能:1个线程比8个好,8个好于2个!

前端之家收集整理的这篇文章主要介绍了linux – 奇怪的nfs性能:1个线程比8个好,8个好于2个!前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我正在尝试确定在同一主机上运行的两个Xen虚拟机(客户端和服务器)之间的nfs性能不佳的原因.具体来说,我可以在客户端上顺序读取1GB文件的速度远低于根据两个VM之间测量的网络连接速度和直接在服务器上读取文件的测量速度所预期的速度. VM正在运行Ubuntu 9.04,服务器正在使用nfs-kernel-server软件包.

根据各种NFS调优资源,更改nfsd线程的数量(在我的情况下是内核线程)会影响性能.通常,这个建议的框架是在大量使用的服务器上增加默认值8的数量.我在当前配置中找到的内容

RPCNFSDCOUNT = 8 :(默认值):13.5-30秒在客户端上获取1GB文件,因此35-80MB /秒

RPCNFSDCOUNT = 16:18s来捕获文件60MB / s

RPCNFSDCOUNT = 1:8-9秒来捕获文件(!!?!)125MB / s

RPCNFSDCOUNT = 2:87s来捕获文件12MB / s

我应该提一下,我正在导出的文件是使用Xen的PCI-passthrough安装在服务器上的RevoDrive SSD上;在服务器上,我可以在几秒钟内(> 250MB / s)捕获文件.我在每次测试之前都在客户端上放置缓存.

我真的不想让服务器配置只有一个线程,因为我猜测当有多个客户端时效果不会很好,但我可能会误解它是如何工作的.我重复了几次测试(在两者之间更改服务器配置),结果相当一致.所以我的问题是:为什么1线程的性能最好?

我试过改变的其他一些事情,很少或没有效果

>将/ proc / sys / net / ipv4 / ipfrag_low_thresh和/ proc / sys / net / ipv4 / ipfrag_high_thresh的值从默认的192K,256K增加到512K,1M
>将/ proc / sys / net / core / rmem_default和/ proc / sys / net / core / rmem_max的值从默认值128K增加到1M
>使用客户端选项安装rsize = 32768,wsize = 32768

从sar -d的输出中我了解到底层设备的实际读取大小相当小(<100字节),但这在客户端本地读取文件时不会引起问题. RevoDrive实际上暴露了两个“SATA”设备/ dev / sda和/ dev / sdb,然后dmraid选择了一个假的RAID-0条纹,我已经挂载到/ mnt / ssd然后绑定挂载到/ export / ssd.我已经使用两个位置对我的文件进行了本地测试,并看到了上面提到的良好性能.
如果答案/评论要求更多细节,我会添加它们.

解决方法

当客户端请求进入时,它将被传递给其中一个线程,并且其余线程被要求执行预读操作.读取文件的最快方法是让一个线程按顺序执行…因此,对于一个文件来说,这是过度的,并且线程本质上为自己做了更多的工作.但是,当您在现实世界中进行部署时,1个客户端读取1个文件的情况并不一定如此,因此请坚持使用基于带宽/ cpu规格的线程数和预读数量的公式.
原文链接:https://www.f2er.com/linux/397742.html

猜你在找的Linux相关文章