Question

我目前正在使用Gluster 3.5处于复制模式的双节点群集。这是为了在尝试在服务器硬件上实现真正的3节点集群之前了解系统。

测试硬件不是高端产品：英特尔凌动D2550和英特尔i5通过Gbit端口上的以太网交叉电缆连接在一起。

在Gluster文件系统中，大约有20,000个小文件（基本上是Debian安装），类似于以后需要处理的实际使用情况（在不同的硬件上）。

由于某些旧软件将在砖块上运行，不幸的是需要定期轮询大多数这些文件，因此轮询文件统计信息时的延迟是一个因素。

我做了一个简单的测试（GlusterFS安装在Gluster节点上）：

# time find | wc -l
22174

real    0m18.542s
user    0m0.224s
sys     0m0.789s

据我所知，这可能是如此之慢，因为GlusterFS必须在每个stat上轮询其他节点。

直接在brick存储目录中进行轮询时，从第二次试用开始，我得到的时间范围为0.16秒（正如预期的那样，所有内容都可以从缓存中读取）。

但是，当我关闭另一个节点，以便只剩下一个节点时，我得到了非常相似的结果：

# time find | wc -l
22174

real    0m16.445s
user    0m0.213s
sys     0m0.702s

怎么会这样？在这种情况下，什么减缓了Gluster？

通常，如何最大限度地减少GlusterFS冗余设置中的读取延迟？如果轮询崩溃之后恢复期间的真实状况暂时落后于实际情况，那么这不会成为一个问题，如果这可以改善转向性能的话。

Answer 1