我们在 2 个节点上运行 GlusterFS 复制服务器，并且有 2 个客户端。已启用自我修复守护进程。每个客户端都使用 Gluster 客户端连接到不同的服务器。Gluster 卷上有很多非常小的文件。
我们在 Debian Jessie 系统上使用来自官方 GlusterFS APT 存储库的 GlusterFS 3.9.1。
我们面临的问题是，其中一台服务器的平均负载为 0.1-0.5，而另一台服务器的平均负载为 200。负载较高的服务器还有大量数据不断流向两个客户端节点。即使客户端没有读写数据，此数据流仍会继续。
以下值由nload和测量iftop：
服务器：传出 35-40 MB/s
两个客户：传入 17-20 MB/s
我们在 Gluster 客户端上的表现非常差。一个任务ls最多需要 10 秒才能完成，而且我们的应用程序运行速度非常慢。
服务器和客户端通过内部数据中心网络连接，可以处理更多的带宽，因此这不是限制因素。
我的主要问题是：
1：服务器负载的这些差异是否是 GlusterFS 的正常行为？这是什么原因造成的？
2：为什么从一台服务器到客户端有如此高的恒定数据流。
我似乎无法在 Gluster 文档或互联网上找到有关此内容的任何信息。
答案1
> 1：这些服务器负载差异是否是 GlusterFS 的正常行为？这是什么原因造成的？
深入了解负载的来源。瓶颈在哪里？CPU/磁盘 IO/...（工具，例如 top、iotop）
也许高负载是基于io-wait。
检查是否有足够的可用内存，以便 gluster 可以使用缓存。
> 2：为什么从其中一个服务器到客户端的数据流如此之高且恒定。
验证哪个程序正在向哪个主机发送哪个数据。nload 和 iftop 可以让您了解整个网络接口的流量。因此，尝试 nethogs，它可以按照 PID 为您提供流量（dev、sent、received）。
客户端的写入必须写入当前 gluster-server。当前 gluster-server 必须将文件发送到另一个 gluster-server。当两个服务器都写入文件后，客户端将收到确认。
也许这个过程会使 gluster-server 上的网络流量“翻倍”！？（请参阅网络监控工具... 哪个进程以及流量流向何处）
一般性能问题：
检查网络延迟并查看Joe Julian 的博客文章 （搜索“跨越高延迟连接”）
如果目录中有很多文件，则 ls 10 秒可能“正常”。这是因为必须从 gluster-server 查询每个文件的所有元数据。请参阅这篇文章解释了 nfs 与 gluster-client 的性能以获得更详细的解释。
也许 http://blog.gluster.org/2016/10/gluster-tiering-and-small-file-performance/ 对你来说很有趣。对我来说，它对小文件性能有一点帮助。