我目前正在复制模式下使用Gluster 3.5的两节点群集。在尝试在服务器硬件上实现真正的3节点群集之前，这是为了对系统有所了解。
测试硬件并不是高端产品：通过Gbit端口上的以太网交叉电缆将Intel Atom D2550和Intel i5连接在一起。
在Gluster文件系统中，大约有20,000个主要是小文件（基本上是Debian安装），这与以后需要处理（在不同硬件上）的实际使用情况类似。
由于某些旧软件将在该砖块上运行，因此不幸的是，需要定期对这些文件中的大多数进行轮询，因此轮询文件统计信息时的延迟是一个因素。
我做了一个简单的测试（将GlusterFS安装在Gluster节点本身上）：
# time find | wc -l
22174
real 0m18.542s
user 0m0.224s
sys 0m0.789s
据我所知，这可能太慢了，因为GlusterFS必须轮询每个
stat上的另一个节点。当直接在砖块存储目录上进行轮询时，从第二次试用开始，我获得的时间范围为0.16秒（如预期的那样，所有内容都可能从缓存中读取）。
但是，当我关闭另一个节点时，只剩下一个节点，我得到的结果非常相似：
# time find | wc -l
22174
real 0m16.445s
user 0m0.213s
sys 0m0.702s
这个怎么可能？在这种情况下，什么会使Gluster变慢？
通常，如何在GlusterFS冗余设置中最小化读取延迟？如果轮询文件系统目录列表在崩溃后恢复期间暂时滞后于实际情况，那可以提高目录列表性能，那将不是问题。
最佳答案
尝试使用NFS兼容性层进行安装。当您有很多小文件时，它实际上会更快：
http://www.gluster.org/community/documentation/index.php/GlusterFS_General_FAQ#Is_the_gluster_client_or_NFS_client_faster.3F