我目前正在使用 Gluster 3.5 复制模式下的两节点集群。这是为了在尝试在服务器硬件上实现真正的 3 节点集群之前对系统有所了解。
测试硬件不是高端的：英特尔凌动 D2550 和英特尔 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 冗余设置中最小化读取延迟？如果在崩溃后的恢复过程中轮询文件系统目录列表会暂时落后于实际情况，那将不是问题，如果这可以提高目录列表的性能的话。