我正在尝试1x2配置的2台Gluster 3.7服务器。服务器通过1 Gbit网络连接。我正在使用Debian Jessie。
我的用例如下：打开文件 - ＆gt;追加64字节 - ＆gt;关闭文件并在一个循环中执行此操作以获得大约5000个不同的文件。如果我通过已安装的glusterfs驱动器访问文件，这种循环的执行时间大约为10秒。如果我直接使用 libgfsapi ，执行时间约为5秒（快2倍）。
但是，在普通的ext4磁盘上，相同的循环在50ms内执行。
Gluster 3.7 end早期版本之间存在巨大的性能差异，我相信这是由于 cluster.eager-lock 设置。
我的目标是在不到1秒的时间内执行循环。
我尝试过很多Gluster设置，但没有成功。具有各种bsize值的 dd 测试表现得像 TCP无延迟选项没有设置，尽管从Gluster源代码看来，默认情况下没有延迟。
知道如何提高性能吗？
修改
我找到了一个适合我案例的解决方案，所以我想分享一下，以防其他人遇到同样的问题。
问题的根本原因是在执行打开/写入/关闭序列期间客户端和Gluster服务器之间的往返次数。我不确切知道背后发生了什么，但时间测量显示了这种模式。现在，显而易见的想法是将打开/写入/关闭序列“打包”到单个写入函数中。粗略地说，这种功能的C原型将是：
int write(const char* fname, const void *buf, size_t nbyte, off_t offset)
但是，libgfapi中已经存在这样的API函数glfs_h_anonymous_write（感谢来自Gluster邮件组的Suomya）。隐藏的东西有文件标识符，它不是普通的文件名，而是struct glfs_object类型的东西。客户端通过API调用glfs_h_lookupat/glfs_h_creat获取此类对象的实例。这里的要点是，表示文件名的glfs_object在某种意义上是“无状态”，相应的inode保持不变（未被引用计数）。应该将glfs_object视为纯文件名标识符并使用它，就像使用文件名一样（实际上，glfs_object将普通指针存储到相应的inode而不重新计算它。）
最后，我们应该使用glfs_h_lookupat/glfs_h_creat一次，并使用glfs_h_anonymous_write多次写入文件。
这样我就可以在 0.5秒中将64个字节追加到5000个文件，这比使用挂载卷和打开//写/关闭序列快20倍。