我正在试验 2 台 Gluster 3.7 服务器的 1x2 配置。服务器通过 1 Gbit 网络连接。我正在使用 Debian Jessie。
我的用例如下：打开文件 -> 追加 64 个字节 -> 关闭文件，并在循环中为大约 5000 个不同的文件执行此操作。如果我通过挂载的 glusterfs 驱动器访问文件，这种循环的执行时间大约为 10 秒。如果我直接使用libgfsapi，执行时间大约是 5 秒（快 2 倍）。
然而，在普通的 ext4 磁盘上，相同的循环在 50 毫秒内执行。
Gluster 3.7 早期版本之间存在巨大的性能差异，我相信这是由于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 倍。