我们在2个节点上运行GlusterFS复制服务器，我们有2个客户端。 自我修复守护程序已启用。 每个客户端都使用Gluster客户端连接到不同的服务器。 Gluster卷上有很多非常小的文件。
我们在Debian Jessie系统上使用官方的GlusterFS APT Repositories中的GlusterFS 3.9.1。
我们面临的问题是其中一台服务器的负载平均为0.1-0.5，而另一台服务器的负载为200.高负载的服务器也有大量的数据不断stream向两个客户端节点。 即使客户端没有读取数据，这个数据stream也会继续。
以下值由nload和iftop测量：
服务器：传出35-40 MB / s
两个客户端：传入17-20 MB /秒
我们在Gluster客户端上的performance非常差。 ls可能需要10秒才能完成，而我们的应用程序工作非常缓慢。
服务器和客户端通过内部数据中心networking连接，可以处理更多带宽，因此这不是一个限制因素。
1： GlusterFS服务器负载正常行为的这些差异是什么造成的？
2：为什么有这么高的常量数据stream来客户端组成一个服务器。
我似乎无法在Gluster文档或互联网上find关于此的任何信息。
> 1：GlusterFS服务器负载正常行为的这些差异是什么原因？
深入了解负载的来源。 瓶颈在哪里？ CPU /磁盘IO / …（工具，如顶，iotop）
也许高负荷是基于等待。
检查是否有足够的空闲内存，所以gluster可以使用caching。
> 2：为什么有这么高的常量数据stream给客户端组成一个服务器。
validation哪个程序正在向哪个主机发送哪些数据。 nload和iftop让你了解整个networking接口的stream量。 所以尝试nethogs给你的stream量（开发，发送，接收）的PID。
客户的写作必须写在当前的gluster服务器上。 当前的gluster-server必须把文件发送给另一个gluster-server。 当两个服务器都写入文件时，客户端会得到确认。
也许这个程序“gluster-server”上的networkingstream量“翻倍”！ （请参阅networking监视工具…哪些进程和哪里去的交通）
一般performance担忧：
检查networking延迟并查看Joe Julian的博客文章 （search“跨高延迟连接”）
如果目录中有很多文件，10秒的ls可能是“正常的”。 这是因为每个文件的每个元数据都必须从gluster-server中查询。 有关更多解释，请参阅此文章解释性能nfs与gluster-client 。
也许http：// blog.gluster.org/2016/10/gluster-tiering-and-small-file-performance/对你来说很有意思。 对我来说，它对小文件性能有一点帮助。